Перейти к основному содержимому

Соответствие требованиям регуляторов и правовая позиция платформы

Версия: 1.0 Дата: 25.04.2026 Статус: Готов к обсуждению

Назначение документа​

Этот документ — детальное раскрытие соответствия требованиям регуляторов (compliance) и правовой позиции (legal posture) платформы Vitiana во всех юрисдикциях первой волны и за её пределами. Документ относится ко второму слою архитектуры (reference/) и раскрывает в глубине то, что в верхнем слое (overview/) зафиксировано тезисно.

Документ отвечает на следующие вопросы:

  • какие регулирования применяются к платформе в каждой целевой юрисдикции (UA, CZ, PL, KZ + EU broader);
  • как требования регуляторов влияют на архитектурные решения по доменам (commercial-model, partner-finance-and-clearing, payment, tour-builder, post-booking-lifecycle);
  • какие compliance-обязательства лежат на платформе как агрегаторе верхнего уровня;
  • какие обязательства лежат на партнёрах, на конечных клиентах;
  • какие технические артефакты обеспечивают compliance в архитектуре;
  • какие операционные процедуры и процессы поддерживают compliance в производстве;
  • какие развилки ещё открыты и требуют решения с пользователем.

Этот документ — блокер для других документов второго слоя: payment-domain.md, tour-builder-operational-model.md, углубление commercial-model.md, partner-finance-and-clearing.md. Решения, зафиксированные здесь, определяют требования к ним.

Главный принцип​

Compliance — first-class архитектурный концерн платформы, не отдельный «потом разберёмся» слой.

Это означает:

  • каждое требование регулятора имеет прямое архитектурное следствие в каноничной модели, контрактах поверхностей, политиках публикации, потоках данных;
  • compliance-обязательства встраиваются в каждый домен по умолчанию (privacy by design, security by design, compliance by design);
  • никаких обязательств «на бумаге» при отсутствии архитектурной реализации;
  • никаких архитектурных решений, которые потом нельзя будет провести через compliance audit (например, hardcoded логика merchant-of-record, mixing PII в analytical events, отсутствие audit trail для критических действий).

При расхождении между удобством разработки и compliance-обязательством — compliance выигрывает.

Связь с правилами и опорными документами​

Правила​

  • Правило 00000 — платформа сама задаёт условия; compliance — следствие целей платформы, не подстройка под отдельных партнёров;
  • Современные лучшие практики — compliance-by-design (Privacy by Design, Security by Design) — стандарт верхнеуровневых SaaS-платформ;
  • Развитие, не деградация — никаких compliance-заглушек («согласие потом», «DSR-эндпоинт пока заглушка»). Каждое обязательство либо реализовано полностью, либо явно отложено с триггером и планом миграции;
  • Тезисное обоснование — каждое compliance-решение обосновано: какое требование регулятора, какая архитектурная реализация, кто несёт ответственность, какой trade-off принят.

Опорные документы первого слоя​

Опорные документы второго слоя​

Часть 1. Карта применимых регулирований​

Платформа Vitiana работает в географии первой волны (Восточная Европа + Казахстан) с расширением в EU broader на фазах 3-4. Каждая юрисдикция имеет собственный набор требований.

1.1. Регулирование Европейского союза​

Применяется ко всем гражданам EU и резидентам, к платформе, обрабатывающей данные граждан EU, к платформе, продающей туристические продукты на территории EU.

GDPR — Общий регламент защиты данных (Регламент EU 2016/679)​

Краткое описание: общеевропейское регулирование защиты персональных данных физических лиц.

Применимость: все персональные данные граждан EU и резидентов EU, независимо от того, где находится контроллер или процессор данных.

Главные обязательства:

  • роли data controller и data processor явно определены;
  • правовое основание (legal basis) для каждой обработки данных (consent, contract, legitimate interest и т.д.);
  • minimization и purpose limitation — собираем только необходимое, для определённой цели;
  • transparency — клиенты знают, какие данные собираются, для чего, с кем шарятся;
  • права субъектов данных (Data Subject Rights, DSR): доступ, исправление, удаление, перенос, ограничение обработки, возражение;
  • breach notification: в течение 72 часов после обнаружения утечки;
  • Data Protection Officer (DPO) обязателен для платформ, обрабатывающих PII в большом масштабе;
  • Data Processing Agreement (DPA) обязателен с каждым процессором (партнёром, под-процессором);
  • privacy impact assessment (PIA) для новых процессов с высоким риском;
  • cross-border transfers требуют механизмов: Standard Contractual Clauses (SCCs), adequacy decisions, BCR.

Связь с архитектурой: см. раздел 3 «GDPR в архитектуре платформы».

EU TOMS — Tour Operators' Margin Scheme (Маржинальный режим НДС для туроператоров)​

Краткое описание: специальный режим VAT для туроператоров. Применяется, когда туроператор продаёт пакетные туристические услуги от своего имени, используя услуги других поставщиков.

Применимость: Vitiana при продаже пакетных туров (≥2 компонентов) от своего имени конечным клиентам в EU.

Главные обязательства:

  • VAT начисляется только на маржу (разницу между ценой клиента и ценой поставщика), не на общую сумму;
  • VAT начисляется в стране резиденции туроператора (Vitiana), не в стране потребления;
  • VAT, уплаченный поставщикам, не подлежит вычету (это часть маржи);
  • отдельный учёт для TOMS-сделок;
  • невозможность выставлять обычные VAT-инвойсы (специфический формат);
  • определённые услуги исключаются (например, домашние услуги в стране туроператора).

Связь с архитектурой: см. раздел 4 «TOMS в коммерческой модели».

Package Travel Directive — Директива EU 2015/2302​

Краткое описание: директива о пакетных туристических продуктах и связанных туристических услугах. Защищает потребителей при покупке пакетных туров.

Применимость: Vitiana и партнёры, продающие пакетные туры (≥2 компонентов: размещение + транспорт, или размещение + другая туристическая услуга составляющая значимую часть).

Главные обязательства:

  • Pre-contractual information requirements: обязательная стандартизированная информация перед заключением договора;
  • Liability for performance: организатор пакетного тура отвечает за исполнение всех компонентов;
  • Insolvency protection: финансовая гарантия (страховой полис, банковская гарантия, escrow account) на случай неплатежеспособности организатора;
  • Right to cancel: клиент имеет право отменить пакет в определённых обстоятельствах;
  • Significant changes notification: уведомление клиента о существенных изменениях с правом отказа;
  • Substitution rules: правила замены организатором при невозможности исполнения;
  • Repatriation obligation: в случае банкротства — обязательная репатриация туристов.

Связь с архитектурой: см. раздел 5 «Package Travel Directive и Tour Builder».

PSD2 / SCA — Strong Customer Authentication (Директива EU 2015/2366)​

Краткое описание: Директива о платёжных услугах второго поколения. Требует усиленную аутентификацию клиентов при онлайн-платежах.

Применимость: все платежи в EU свыше 30 евро (с некоторыми исключениями).

Главные обязательства:

  • Strong Customer Authentication (SCA) на основе двух из трёх факторов: knowledge (пароль), possession (телефон), inherence (биометрия);
  • 3D Secure 2.0 (3DS) как стандартный механизм SCA для карточных платежей;
  • исключения (low value, recurring, trusted beneficiaries) применимы при определённых условиях;
  • merchant initiated transactions (MIT) разрешены при правильной настройке.

Связь с архитектурой: см. документ payment-domain.md (создаётся следующим в Группе 1).

DAC7 — Директива об административном сотрудничестве в области налогообложения​

Краткое описание: директива EU, обязывающая цифровые платформы отчитываться о sellers и transactions перед налоговыми органами.

Применимость: Vitiana как онлайн-платформа, посредничающая в продажах туристических услуг.

Главные обязательства:

  • сбор и проверка identification data партнёров (sellers): имя, юридический адрес, налоговый идентификатор, IBAN;
  • ежегодная отчётность перед налоговым органом одной EU-страны (residence) с информацией о sellers и их sales за календарный год;
  • уведомление sellers о собранных и отправленных данных;
  • штрафы за несвоевременную или неполную отчётность.

Связь с архитектурой: см. раздел 6 «DAC7 и DSA: обязательства платформы как online intermediary».

Digital Services Act (DSA) — Регламент EU 2022/2065​

Краткое описание: регламент о цифровых услугах. Устанавливает обязательства для онлайн-платформ по transparency, illegal content, recommender systems.

Применимость: Vitiana как online platform.

Главные обязательства:

  • единый contact point для регуляторов и пользователей;
  • terms and conditions в понятной форме;
  • transparency reports о moderation actions;
  • notice-and-action mechanism для illegal content (например, поддельные предложения, fraudulent listings);
  • dispute settlement systems для conflicts между sellers и customers;
  • protection of minors (если применимо);
  • explanation of recommender systems (если используется ML для ranking);
  • VLOP/VLOSE дополнительные обязательства для very large online platforms (Vitiana пока не подпадает; на фазе 4 при росте — возможно).

Связь с архитектурой: см. раздел 6 «DAC7 и DSA».

Consumer Rights Directive (Директива EU 2011/83/EU) и национальные имплементации​

Краткое описание: общие права потребителей при онлайн-покупках в EU.

Применимость: все B2C продажи в EU.

Главные обязательства:

  • pre-contractual information requirements;
  • 14-дневный right of withdrawal для дистанционных покупок (с исключениями для туристических услуг — см. ниже);
  • delivery and risk passing rules;
  • cooling-off periods.

Особенность для туристических услуг: многие туристические услуги исключены из 14-дневного права отказа (Article 16(l): услуги размещения, транспорта, аренды автомобилей, питания и досуга, оказываемые в определённую дату или период).

Связь с архитектурой: см. документ post-booking-lifecycle.md — refund/cancellation/withdrawal rules.

1.2. PCI DSS — Payment Card Industry Data Security Standard​

Краткое описание: международный стандарт безопасности данных индустрии платёжных карт. Не государственное регулирование, а отраслевой стандарт, поддерживаемый Visa, Mastercard, American Express, Discover, JCB.

Применимость: любая организация, обрабатывающая, хранящая или передающая данные платёжных карт.

Главные обязательства:

  • 12 high-level требований, разделённые на 6 групп (защита сети, защита cardholder data, vulnerability management, access control, monitoring, security policy);
  • 4 уровня compliance (1-4) в зависимости от объёма транзакций;
  • регулярные аудиты (Self-Assessment Questionnaire или Qualified Security Assessor).

Стратегия Vitiana: минимизация PCI scope через delegation к PSP. Платформа никогда не обрабатывает и не хранит cardholder data напрямую. Карточные данные передаются клиентом непосредственно к PSP (Stripe, Adyen, или эквивалент), который handles PCI compliance. Vitiana работает на уровне SAQ A (минимальный уровень) или SAQ A-EP (с redirected/iframe форматом).

Связь с архитектурой: см. документ payment-domain.md.

1.3. Регулирование Украины​

Закон Украины «Про захист персональних даних» (№ 2297-VI)​

Краткое описание: украинский закон о защите персональных данных. С 2014 года — постепенная гармонизация с GDPR через Association Agreement с EU.

Применимость: обработка персональных данных украинских граждан и резидентов.

Главные обязательства (с учётом гармонизации):

  • регистрация баз персональных данных (исторически; в современной редакции регистрация упрощена);
  • consent для обработки;
  • DSR (с национальными особенностями);
  • cross-border transfer ограничения;
  • breach notification.

Стратегия Vitiana: при правильной реализации GDPR требования украинского закона в основном покрываются автоматически. Дополнительные требования: украиноязычные privacy notices, контактный representative в Украине, локальное хранение определённых категорий данных при необходимости.

Связь с архитектурой: GDPR-инфраструктура поддерживает требования; локализация privacy notices и terms of service.

Налоговое регулирование Украины​

  • VAT/ПДВ при продажах в Украине;
  • corporate tax обязательства;
  • specific режим для travel agents (при наличии лицензии туроператора в Украине).

Стратегия Vitiana: для продаж в Украине через vitrip.store или украинских агентств — настройка VAT-учёта в украинской юрисдикции. Для платформенных услуг партнёрам в Украине — обычные B2B VAT правила.

Связь с архитектурой: см. документ commercial-model.md — VAT logic.

Туроператорская лицензия (если применимо)​

В Украине деятельность туроператора требует лицензии. Турагент работает по упрощённой схеме.

Стратегия Vitiana: при продаже пакетных туров от своего имени в Украине через vitrip.store — необходимо оценить, требуется ли туроператорская лицензия. Открытая развилка, эскалируется для решения с украинским юристом.

1.4. Регулирование Чехии и Польши​

EU-юрисдикции, поэтому применяется весь набор EU-регулирований (GDPR, TOMS, Package Travel Directive, PSD2, DAC7, DSA) плюс национальные имплементации.

Особенности:

  • Чехия: чешский закон о защите данных (Zákon č. 110/2019 Sb., о zpracování osobních údajů) — национальная имплементация GDPR;
  • Польша: Ustawa o ochronie danych osobowych — национальная имплементация GDPR;
  • VAT registration в каждой стране при превышении distance selling threshold;
  • локальные потребительские права (cooling-off periods, refund procedures);
  • локальные требования по выдаче чеков (cash registers in Czech Republic, JPK_VAT в Польше).

Стратегия Vitiana: EU-готовая infrastructure покрывает 90% требований; локализация privacy notices, terms of service, customer support; VAT-регистрация при превышении thresholds.

1.5. Регулирование Казахстана​

Закон Республики Казахстан «О персональных данных и их защите» (№ 94-V)​

Краткое описание: казахстанский закон о защите персональных данных. С 2013 года — собственный режим, не идентичный GDPR.

Главные обязательства:

  • регистрация баз персональных данных;
  • consent для обработки;
  • localization requirement: данные граждан Казахстана должны храниться на серверах в Казахстане (обязательно с 2016 года);
  • DSR с национальными особенностями;
  • cross-border transfer требует разрешения.

Стратегия Vitiana:

  • Localization requirement критично: для обслуживания казахстанских клиентов и партнёров в полной мере необходим датацентр в Казахстане (фаза 3-4) или специальная схема (например, обслуживание через казахстанского партнёра-резидента, который handles локальное хранение). Open question — развилка с пользователем.
  • На фазе 1-2 — обслуживание казахстанских клиентов через украинских/чешских партнёров (партнёр становится data controller в Казахстане).

Связь с архитектурой: см. раздел 8 «Data residency и cross-border transfer».

Налоговое регулирование Казахстана​

  • VAT/НДС в Казахстане;
  • corporate tax;
  • digital services tax (если применимо);
  • VAT on B2C electronic services rule (с 2022 года иностранные платформы должны регистрироваться для VAT).

Стратегия Vitiana: при значимом объёме B2C-продаж в Казахстане — VAT registration. При работе через казахстанских партнёров — партнёры handles локальный VAT.

1.6. Сводная таблица применимости​

РегулированиеUACZPLKZEU broader
GDPRчерез DPA при transferдадачерез DPA при transferда
EU TOMSнет (UA не EU)даданетда
Package Travel Directiveчерез гармонизациюдаданет (но есть аналог)да
PSD2 / SCAв развитии (для EUR-платежей)даданетда
DAC7через гармонизациюдаданетда
DSAчерез гармонизациюдаданетда
PCI DSSда (отраслевой)дададада
UA Personal Data Lawданетнетнетнет
KZ Personal Data Lawнетнетнетданет
Localization requirementнетнет (EU)нет (EU)данет
Туроператорская лицензиявозможновозможновозможновозможноразное

Часть 2. Цепочка ответственности и compliance-следствия​

Цепочка merchant-of-record платформы (классическая модель агрегатора, гибридная per-tenant) — детально описана в overview/architectural-anchor-and-business-model.md. Её compliance-следствия раскрываются здесь.

2.1. Три модели merchant-of-record​

Модель A. Платформа сама merchant-of-record (Platform-as-MoR)​

Применяется для: собственного канала vitrip.store; некоторых tenant tier (Starter с базовой платёжной интеграцией).

Compliance-следствия:

  • Vitiana — data controller для персональных данных конечных клиентов;
  • Vitiana — payment processor responsibility (через PSP delegation);
  • Vitiana — package travel organiser при продаже пакетных туров → insolvency protection обязателен;
  • Vitiana — tax/VAT обязательства в стране резиденции (для TOMS) или стране потребления (для non-TOMS);
  • Vitiana ведёт DAC7 reporting обо всех transactions через эту модель.

Модель B. Партнёр сам merchant-of-record (Partner-as-MoR)​

Применяется для: крупных B2B-партнёров с собственной платёжной системой; Enterprise tier обычно работает по этой модели.

Compliance-следствия:

  • Партнёр — data controller для своих конечных клиентов;
  • Vitiana — data processor для партнёра (DPA обязателен между Vitiana и партнёром);
  • Партнёр — payment processor responsibility;
  • Партнёр — package travel organiser (если применимо) → insolvency protection на стороне партнёра;
  • Партнёр — tax/VAT обязательства в своей юрисдикции;
  • Партнёр ведёт свой DAC7 reporting (если он EU-платформа);
  • Vitiana — DAC7 reporting только на партнёра как seller.

Модель C. Гибрид — разные продукты разные модели (Hybrid)​

Применяется для: случаев, когда tenant хочет разные модели для разных продуктов — например, tour packages по Модели A (Vitiana — package travel organiser), отдельные hotel bookings по Модели B (партнёр — MoR).

Compliance-следствия: комбинация A и B per продукт, явно зафиксированная в Tenant Configuration.

2.2. Архитектурные решения, диктуемые цепочкой​

  • Tenant Configuration содержит явное поле merchant_of_record_model с значениями platform, partner, hybrid;
  • DPA registry — каждый tenant имеет attached DPA с явными ролями;
  • Sub-processor lists — per tenant, поддерживается история изменений с уведомлением партнёра при добавлении нового sub-processor;
  • Per-product MoR resolution — для гибридной модели логика resolution per booking;
  • Insolvency protection registry — per tenant per юрисдикция;
  • VAT calculation engine — выбирает правильный режим (TOMS / standard / partner-handled) per booking on the fly.

Часть 3. GDPR в архитектуре платформы​

GDPR — самое требовательное регулирование в первой волне. Архитектура реализует GDPR-by-design через следующие механизмы.

3.1. Минимизация PII (data minimization)​

Принцип: собираем только те персональные данные, которые необходимы для конкретной цели.

Архитектурная реализация:

  • каноничная модель разделяет обязательные PII (имя, контакт для booking — без них невозможно исполнение договора), факультативные PII (для маркетинга, рекомендаций — требуют отдельного consent), технические идентификаторы (без PII — anonymized);
  • для каждого поля каноничной модели — явная классификация privacy class:
    • pii_essential — необходимо для исполнения договора (legal basis: contract);
    • pii_optional_consent — требует opt-in consent (legal basis: consent);
    • pii_legitimate_interest — обоснованный интерес платформы (legal basis: legitimate interest, документированный assessment);
    • non_pii — не персональные данные;
    • pseudonymized — псевдонимизированные (хешированные user IDs);
    • anonymized — анонимизированные (нет возможности re-identification).

3.2. Purpose limitation​

Принцип: данные используются только для целей, для которых были собраны.

Архитектурная реализация:

  • purpose registry — каждое назначение использования данных явно зарегистрировано: booking_execution, customer_support, marketing_communication, recommendation_personalization, fraud_prevention, analytics_aggregated, legal_obligation, audit;
  • каждое поле каноничной модели имеет attached список purposes, для которых оно используется;
  • runtime checks: при попытке использовать поле для purpose, не указанного в registry — denial с audit log entry;
  • analytical events содержат только данные, релевантные для analytical purposes (не PII в большинстве случаев).

3.3. Права субъектов данных (Data Subject Rights, DSR)​

GDPR предоставляет физическим лицам семь прав. Архитектура реализует все семь.

Right to access (Article 15)​

Что требуется: субъект может запросить копию всех своих персональных данных, обрабатываемых платформой.

Архитектурная реализация:

  • DSR Service — отдельный микросервис, обрабатывающий DSR-запросы;
  • Subject identification — верификация запроса (через email confirmation + secondary factor);
  • Cross-domain query — DSR Service делает запросы ко всем доменам, содержащим данные о subject: canonical entities (User, traveler info в Bookings), supplier trace (если есть PII), operational layer (Quote, Offer references), transactional (Booking history), governance (review cases с participation), analytical events (anonymized, но связанные через subject ID), media (uploaded photos);
  • Аккумулирование результата в стандартизированный JSON или PDF report;
  • SLA на ответ: 30 дней (по GDPR), целевое — 7 дней;
  • Audit log каждого DSR-запроса.

Right to rectification (Article 16)​

Что требуется: субъект может потребовать исправить неточные данные.

Архитектурная реализация:

  • self-service editing для базовых полей профиля;
  • request workflow для полей, требующих verification (имя, дата рождения, паспорт);
  • canonical entity update propagates to all derived projections (search projection, analytical events не меняются — они immutable, но новые events отражают новые данные);
  • audit log с before/after.

Right to erasure / Right to be forgotten (Article 17)​

Что требуется: субъект может потребовать удаления своих данных.

Архитектурная реализация:

  • Erasure Service — отдельный workflow с эскалацией к governance review (некоторые удаления невозможны из-за legal obligations — например, transaction records для tax purposes должны храниться 5-10 лет);
  • Tombstone pattern — данные marked как deleted в каноничной модели, но физически не удаляются immediately (в течение 30 дней — grace period для отмены);
  • Deep deletion — после grace period: cascading deletion в supplier trace (PII в нём анонимизируется), operational layer (PII в quotes/offers удаляется), transactional layer (booking сохраняется, PII заменяется на placeholder для legal retention), analytical events (анонимизированный subject ID удаляется или заменяется на one-way hash);
  • Что не удаляется: транзакционные записи о bookings (требуются для tax retention 5-10 лет, depending on jurisdiction); GDPR явно допускает retention для legal obligations;
  • Tenant notification — при удалении PII клиента уведомляется tenant, который может иметь свои copies (он становится independent controller с собственными обязательствами).

Right to restriction of processing (Article 18)​

Что требуется: субъект может ограничить обработку своих данных в определённых обстоятельствах.

Архитектурная реализация:

  • flag processing_restricted на subject;
  • runtime check: при попытке обработки restricted данных — denial кроме операций, явно разрешённых при restriction (storage, legal claims, protection of others' rights, public interest).

Right to data portability (Article 20)​

Что требуется: субъект может получить свои данные в machine-readable формате и передать другому контроллеру.

Архитектурная реализация:

  • Portability Service — отдельный workflow, экспортирующий данные в structured формат (JSON-LD, CSV);
  • субъект получает архив со всеми portable данными (booking history, profile, preferences) в стандартном формате;
  • Interoperability — Vitiana поддерживает стандартные туристические форматы (NDC, OTA standards) при экспорте, чтобы другие платформы могли импортировать.

Right to object (Article 21)​

Что требуется: субъект может возразить против обработки на основании legitimate interest или для marketing.

Архитектурная реализация:

  • self-service opt-out для marketing communications;
  • request workflow для objection к legitimate interest processing с governance review;
  • при принятии objection — обработка прекращается immediately, audit log entry.

Rights related to automated decision-making (Article 22)​

Что требуется: субъект имеет право не быть подверженным automated decision-making, которое имеет legal effect или significantly affects.

Применимость в Vitiana:

  • dynamic pricing — может затрагивать клиента (price personalization);
  • fraud detection — может приводить к отказу в booking;
  • search ranking — обычно не имеет legal effect, но может быть rest-восприниматься как discrimination.

Архитектурная реализация:

  • transparency — subject имеет право узнать о использовании automated decision-making (в privacy notice);
  • human review — subject имеет право требовать human review automated decision;
  • explainability — для critical automated decisions хранится explanation (которые модели использовались, какие features имели наибольший вес);
  • ML platform (см. overview/data-and-intelligence-spine.md) поддерживает explainable AI для models, влияющих на subjects.

3.4. Lawful basis registry​

Что требуется: для каждой обработки PII должно быть документированное legal basis.

Архитектурная реализация:

  • Lawful Basis Registry — реестр всех processing activities с явным legal basis;
  • классификация по 6 GDPR legal bases: consent, contract, legal obligation, vital interests, public task, legitimate interests;
  • для legitimate interest — обязательный Legitimate Interest Assessment (LIA) с документированной балансировкой interests;
  • audit trail изменений legal basis (если процесс перепроходит через assessment).

Что требуется: для consent-based processing — granular, freely given, specific, informed, unambiguous consent с возможностью withdrawal.

Архитектурная реализация:

  • Consent Management Service — отдельный сервис с consent records;
  • granular consent (отдельный для marketing, recommendation personalization, analytics, etc.);
  • consent UI с явным opt-in (no pre-checked boxes);
  • consent versioning — изменение privacy policy → re-consent;
  • withdrawal — equally easy as giving consent;
  • consent audit trail с timestamps, IP, user agent.

3.6. Data Processing Agreements (DPA)​

Что требуется: обязательный contract между controller и processor с явными ответственностями.

Архитектурная реализация:

  • DPA Registry — реестр DPA для каждого партнёра-tenant и каждого sub-processor;
  • стандартизированный DPA template;
  • versioning — изменения DPA требуют notification партнёра;
  • self-service в Partner Console: партнёр видит текущий DPA, историю изменений, может скачать подписанные копии.

3.7. Sub-processor lists​

Что требуется: controller обязан раскрывать sub-processors процессорам и получать прямое или общее consent на их использование.

Архитектурная реализация:

  • Sub-processor Registry — список всех third-party processors, используемых платформой (PSP, cloud providers, email service providers, etc.);
  • per-tenant view — какие sub-processors применяются к данным конкретного tenant;
  • notification mechanism — добавление sub-processor → email уведомление + 30-day grace period для objection;
  • partner может opt-out с alternative arrangement (если технически возможно) или прекратить сотрудничество.

3.8. Cross-border transfer mechanisms​

Что требуется: transfer персональных данных за пределы EEA (EU + Iceland, Liechtenstein, Norway) требует адекватной защиты.

Применимость для Vitiana:

  • transfer EU → UA: requires SCC + supplementary measures (UA не имеет adequacy decision);
  • transfer EU → KZ: requires SCC + supplementary measures (KZ не имеет adequacy decision);
  • transfer внутри EU: free flow, no special mechanisms.

Архитектурная реализация:

  • SCC Module Templates для transfers EU → UA, EU → KZ;
  • Transfer Impact Assessment (TIA) для каждого transfer pattern;
  • supplementary measures: encryption in transit, encryption at rest, access controls, audit logs, data minimization;
  • option для tenants выбрать data residency (хранить EU-данные только в EU-датацентрах, фаза 3-4 при появлении dedicated infrastructure).

3.9. Breach notification​

Что требуется: уведомление supervisory authority в течение 72 часов после обнаружения breach; уведомление subjects при high risk.

Архитектурная реализация:

  • Breach Detection Pipeline — анализ security events, anomaly detection (на ML platform), alerts при подозрительной активности;
  • Incident Response Playbook — формальная procedure для breach response (см. документ operations/runbooks-incident-playbooks.md фазы 6);
  • Breach Notification Service — автоматизированный workflow для уведомления authorities и subjects;
  • audit trail каждого breach response.

3.10. Data Protection Officer (DPO)​

Что требуется: DPO обязателен для платформ, обрабатывающих PII в большом масштабе.

Стратегия Vitiana:

  • DPO appointment на фазе 2 при появлении первых платных партнёров и реальной нагрузки на PII;
  • DPO contact information в privacy policies и Partner Console;
  • DPO independent reporting line к executive level.

Архитектурная реализация:

  • DPO имеет dedicated tooling: dashboard всех DSR requests, breach notifications, ongoing PIAs, sub-processor changes;
  • DPO contact email + dedicated channel для DSR submissions.

3.11. Privacy Impact Assessment (PIA / DPIA)​

Что требуется: обязательный для high-risk processing (например, large-scale, sensitive data, profiling, automated decision-making).

Применимость в Vitiana:

  • ML-driven dynamic pricing — DPIA;
  • ML-driven fraud detection — DPIA;
  • recommendation personalization — DPIA;
  • cross-border transfers UA/KZ — DPIA + TIA.

Архитектурная реализация:

  • DPIA Workflow — формальная procedure для проведения PIA перед запуском нового processing;
  • DPIA template с обязательными разделами: purposes, legal basis, data flow, risks, mitigation;
  • DPIA registry — все проведённые PIAs хранятся;
  • annual DPIA review для existing processing.

3.12. Audit log как never-deleted layer​

Что требуется: аудитируемость всех действий с PII.

Архитектурная реализация:

  • Audit Log Service — append-only хранение всех access events к PII;
  • Что логируется: кто (subject identity), что (operation: read/write/delete), когда (timestamp), откуда (IP, user agent), на каких данных (subject of operation), legal basis (cited);
  • Где живёт: отдельный storage class (см. reference/storage.md), retention 6 лет (можно дольше);
  • Доступ к audit log: только DPO, security team, compliance auditors;
  • audit log immutable — не может быть изменён или удалён никем включая administrators.

Часть 4. TOMS в коммерческой модели​

EU TOMS (Tour Operators' Margin Scheme) — специальный VAT режим для туроператоров. Влияет на commercial model и settlement.

4.1. Когда применяется​

TOMS применяется при следующих условиях:

  • турист — резидент EU;
  • туроператор продаёт в собственном имени (от своего имени, не как агент);
  • туроператор использует поставленные услуги других (отель, транспорт, экскурсии куплены у third parties).

Vitiana попадает под TOMS при:

  • продаже tour packages через vitrip.store от своего имени конечным клиентам в EU (Модель A merchant-of-record);
  • partner с Моделью A merchant-of-record — partner подпадает под TOMS, если он EU-резидент.

Не попадает под TOMS:

  • продажа собственных услуг (Vitiana own-supplied — нет в текущей модели);
  • продажа от имени другого (agency relationship);
  • продажа non-EU клиентам.

4.2. Архитектурные следствия​

4.2.1. Margin calculation​

Что требуется: VAT начисляется только на маржу (price to customer minus cost of supplied services).

Архитектурная реализация:

  • commercial model (см. reference/commercial-model.md) различает 5 уровней цены: supplier raw → normalized base → commercial rule output → quoted → settlement-relevant;
  • TOMS margin = quoted_price - sum(supplier_costs);
  • VAT on margin = margin × VAT_rate (rate в стране резиденции туроператора);
  • хранение margin trace: для каждого booking сохраняется breakdown — supplier cost + Vitiana margin + applied VAT.

4.2.2. VAT in country of establishment​

Что требуется: VAT начисляется в стране резиденции туроператора, не в стране потребления.

Архитектурная реализация:

  • Tenant Configuration содержит поле tax_residence per merchant-of-record entity;
  • VAT calculation engine применяет правильный режим per booking based on:
    • merchant-of-record entity (Vitiana или partner);
    • tax residence этого entity;
    • применимость TOMS (EU customer + own-name + supplied services).

4.2.3. Non-deductible input VAT​

Что требуется: VAT, уплаченный supplier, не подлежит вычету.

Архитектурная реализация:

  • accounting layer хранит supplier invoices с VAT, но НЕ recovers этот VAT (входной НДС не зачитывается);
  • supplier costs в settlement traces включают полный VAT-inclusive amount.

4.2.4. Special invoicing​

Что требуется: TOMS-сделки имеют specific формат инвойса (no breakdown of VAT to customer).

Архитектурная реализация:

  • Invoice Generator имеет TOMS template — без breakdown VAT;
  • standard invoices для non-TOMS sales;
  • per-booking determination какой template применить.

4.2.5. Excluded services​

Что требуется: некоторые услуги исключаются из TOMS (например, услуги, оказанные туроператором собственными силами в стране резиденции).

Стратегия Vitiana: на текущем scope — нет own-supplied услуг, все услуги — supplied от третьих сторон. Все packages подпадают под TOMS.

4.3. Связь с partner finance​

Partner с Моделью A (Partner-as-MoR) handles свой TOMS независимо. Vitiana не делает TOMS calculation для партнёра — это его обязанность.

Partner с Моделью B (Platform-as-MoR через Vitiana) — Vitiana делает TOMS calculation, partner получает settlement netto от TOMS-margin. Partner-facing analytics показывают TOMS impact в commercial breakdown.

Часть 5. Package Travel Directive и Tour Builder​

EU Package Travel Directive 2015/2302 защищает потребителей при покупке пакетных туров. Прямо влияет на Tour Builder.

5.1. Когда применяется​

Package travel определяется как комбинация минимум двух из следующих типов услуг для одного и того же путешествия:

  • transport (авиа, ж/д, водный, дорожный);
  • accommodation (отель, апартаменты);
  • rental of motor vehicles or motorcycles;
  • any other tourist service не intrinsic к перечисленным выше (если составляет significant proportion от value или представляется как essential feature пакета).

Vitiana Tour Builder создаёт packages при сочетании ≥2 из этих типов через accommodation segment + transfer segment + activity + service modules.

Linked travel arrangements — отдельная категория с менее строгими, но всё ещё регулируемыми обязательствами.

5.2. Кто package travel organiser​

В контексте Vitiana:

  • Vitiana — organiser при продаже tour package через vitrip.store от своего имени (Модель A);
  • Partner — organiser при продаже tour package через свой канал (Модель B);
  • Гибрид — определяется per booking по продуктовому типу.

Этот выбор определяется в Tenant Configuration и Tour Builder Closed Surface при создании tour proposal.

5.3. Pre-contractual information requirements​

Что требуется: перед заключением договора клиент получает обязательную стандартизированную информацию.

Стандартизированная информация (Annex I directive):

  • main characteristics of services (destination, dates, transport mode, accommodation type, meals, excursions, group size, language);
  • trading name and contact details организатора;
  • total price включая taxes и additional fees;
  • payment arrangements;
  • minimum number of persons required (если applicable);
  • legal requirements (passport, visa, health requirements);
  • general information о cancellation rights;
  • insolvency protection details.

Архитектурная реализация:

  • Pre-contractual Information Generator — компонент Tour Builder, генерирующий стандартизированный document перед checkout;
  • multi-language (UA/RU/CZ/PL/EN/KZ) versions автоматически;
  • хранение exact version document, представленной клиенту, в booking record (immutable).

5.4. Liability for performance​

Что требуется: organiser отвечает за исполнение всех компонентов package, независимо от того, кто их фактически предоставляет.

Архитектурные следствия:

  • Vitiana как organiser (Модель A) — отвечает перед клиентом за каждый компонент: размещение, транспорт, активности;
  • при failure поставщика (отель не принял, transfer не приехал) — Vitiana обязана либо предоставить replacement, либо refund;
  • Substitution rules — Vitiana может заменить компонент при невозможности оригинального исполнения, но клиент имеет право отказаться от substitution и получить refund;
  • Compensation rules — при significant failure клиент имеет право на price reduction or compensation.

Архитектурная реализация:

  • Post-Booking Lifecycle (см. reference/post-booking-lifecycle.md) включает scenarios для supplier disruption, substitution, compensation;
  • Customer Communication Service автоматизирует уведомления клиента о substitutions с правом отказа;
  • Refund Engine обрабатывает refunds при невозможности substitution.

5.5. Insolvency protection​

Что требуется: organiser обязан обеспечить insolvency protection — финансовую гарантию, что в случае банкротства клиенты получат:

  • refund всех уплаченных сумм;
  • repatriation (если уже в путешествии).

Mechanisms:

  • страховой полис (insurance policy) у специализированного insurer;
  • банковская гарантия (bank guarantee);
  • escrow account (trust fund);
  • участие в государственной schema (если есть в стране резиденции).

Стратегия Vitiana:

  • Phase 2 onset: при первых package travel sales — обязательно один из mechanisms;
  • предпочтительно — страховой полис у specialized travel insurer (например, AIG Travel Guard, Allianz Global Assistance, или local equivalent);
  • Tenant requirement: партнёры с Моделью A (Partner-as-MoR) обязаны иметь свой insolvency protection. Verification — часть certification flow (см. overview/platform-as-product.md);
  • Insolvency protection registry в Tenant Configuration — какой mechanism, какой insurer, какой sum insured, validity period;
  • automated alerts при approaching expiry — partner notification + suspension of new bookings.

5.6. Right to cancel before departure​

Что требуется: клиент имеет право cancel пакет до departure с возвратом за вычетом reasonable cancellation fee.

При unavoidable extraordinary circumstances в destination — full refund.

Архитектурная реализация:

  • Cancellation Engine в post-booking lifecycle с rules:
    • standard cancellation fees per supplier (передаются от поставщиков);
    • extraordinary circumstances detection (война, природные катастрофы, эпидемии в destination);
    • in extraordinary cases — automatic full refund without cancellation fee.

5.7. Significant changes notification​

Что требуется: при significant changes (price increase >8%, change in destination, change in dates, change in accommodation category) — обязательное уведомление с правом отказа.

Архитектурная реализация:

  • Drift Detection в Tour Builder отслеживает изменения в underlying offers после publication;
  • threshold detection: 8% price change, destination change, date change, category change;
  • automatic customer notification с явным правом отказа;
  • если refusal — full refund без penalty.

5.8. Архитектурные требования к Tour Builder​

См. документ tour-builder-operational-model.md (фаза 5). Key compliance requirements:

  • Module classification включает tourist_service_intrinsic и tourist_service_significant flags для определения, попадает ли combination под Package Travel;
  • Auto-classification combination как package travel при ≥2 covered services;
  • Pre-contractual document generation — обязательная procedure перед checkout;
  • Liability tracking — для каждого component — кто supplier, какие cancellation/substitution rules применяются, какие compensation в случае failure;
  • Drift handling — automatic detection of significant changes с customer notification workflow.

Часть 6. DAC7 и DSA — обязательства платформы как online intermediary​

6.1. DAC7 — Tax reporting обязательства​

Что требуется: ежегодная отчётность перед налоговыми органами одной EU-страны (residence) с информацией о sellers (партнёрах) и их sales.

Применимость: Vitiana обязана reporting, если резидент EU-страны. На текущем scope — Vitiana может быть EU-резидентом (registration в Чехии или Польше) или non-EU (Ukrainian entity). Open question — развилка с пользователем.

Если Vitiana — EU-resident platform:

Reporting obligations:

  • collect и verify identification data sellers: name, registered address, tax identifier, VAT ID, IBAN;
  • annually report transactions per seller per quarter;
  • threshold filtering: только sellers above certain threshold reportable (€2000+ или 30+ transactions per year);
  • notify sellers о data, отправленных в reporting;
  • store reporting data 5 лет.

Архитектурная реализация:

  • Seller Identity Verification Service — часть partner certification flow;
  • DAC7 Reporting Engine — automatic aggregation of qualifying transactions per seller per period;
  • Annual reporting workflow — generation reports в Tax Authority format, submission через secure channel;
  • Seller notification — annual notice к каждому partner с copy reportable data.

6.2. DSA — Digital Services Act обязательства​

Что требуется: transparency, illegal content handling, recommender systems explanation, dispute resolution.

Применимость: Vitiana как online platform.

Обязательства:

Single contact point​

  • single contact point для регуляторов и пользователей;
  • representative в EU для non-EU established platforms.

Архитектурная реализация: publication contact information в footer, terms, dedicated email + form.

Terms and conditions transparency​

  • T&C в clear and accessible form;
  • specific provisions для recommender systems, content moderation, account termination.

Архитектурная реализация: structured T&C documents per tenant tier с явными секциями для DSA-required content.

Notice-and-action mechanism​

  • mechanism для notice illegal content (например, fraudulent listings, поддельные предложения);
  • transparent action timeline;
  • notification submitter и affected party.

Архитектурная реализация:

  • Content Moderation Workflow — submission portal + governance review queue + decision logging;
  • automated detection (на ML platform — image moderation, text analysis) для known patterns;
  • human review для borderline cases.

Internal complaint-handling system​

  • system для dispute resolution между sellers (партнёрами) и customers (если applicable);
  • access for affected users.

Архитектурная реализация: часть Internal Operational Surface — dispute ticketing с structured workflow.

Out-of-court dispute settlement​

  • access к accredited out-of-court dispute settlement bodies для disputes между marketplace и users.

Архитектурная реализация: publication of accredited bodies in T&C.

Recommender systems explanation​

  • main parameters of recommender systems explained в T&C;
  • option для users adjust parameters (если technically feasible).

Архитектурная реализация:

  • Recommender Explanation в каждом recommender output: «recommended on basis of X, Y, Z factors»;
  • option disable_personalization в user settings → falls back на non-personalized recommendations.

Reporting​

  • annual transparency reports о moderation actions, complaints, disputes.

Архитектурная реализация: Transparency Report Generator — автоматическая аннотация и публикация на public website.

6.3. VLOP / VLOSE additional обязательства​

При reach 45M+ EU users monthly — статус Very Large Online Platform с дополнительными обязательствами:

  • systemic risk assessment;
  • mandatory audit;
  • crisis response mechanisms;
  • data access для researchers.

Стратегия Vitiana: на текущем scope не VLOP. На фазе 4+ при кросс-EU expansion — переоценка применимости.

Часть 7. AML/KYC на партнёров​

Anti-Money Laundering / Know Your Customer — обязательная procedure при certification партнёров с финансовой interaction (особенно с credit-based clearing model).

7.1. Когда применяется​

  • при partner certification — обязательная KYC для всех платных партнёров;
  • при financial interactions — AML monitoring transactions partners;
  • при suspicious activity — escalation to financial authorities (FIU — Financial Intelligence Unit).

7.2. KYC процедура​

Архитектурная реализация:

  • KYC Workflow в partner certification flow;
  • KYC requirements per tier:
    • Free tier: basic email + identity verification;
    • Starter tier: company registration documents, beneficial owner identification, tax ID;
    • Professional tier: above + financial statements, references;
    • Enterprise tier: above + extended due diligence, sanctions screening;
  • Sanctions screening — automated check против EU/UN/OFAC sanctions lists;
  • PEP (Politically Exposed Person) screening — automated check для beneficial owners;
  • High-risk country screening — additional review для partners в high-risk jurisdictions;
  • Periodic re-verification — annual re-KYC для Professional+ tiers.

7.3. AML monitoring​

Архитектурная реализация:

  • Transaction Monitoring Service — анализ partner transactions на ML platform для anomaly detection;
  • Suspicious pattern detection — high-velocity transactions, structuring, unusual booking patterns, payments to high-risk jurisdictions;
  • SAR (Suspicious Activity Report) workflow — escalation to compliance team → potential reporting to FIU;
  • Audit trail — все monitoring decisions stored.

Часть 8. Data residency и cross-border transfer​

8.1. Data residency requirements​

Жёсткие requirements:

  • Казахстан: данные граждан Казахстана должны храниться на серверах в Казахстане (с 2016).

Soft preferences:

  • EU customers могут предпочитать EU-only storage (часть Enterprise SLA);
  • некоторые корпоративные клиенты требуют local data residency как часть contracts.

8.2. Архитектурные следствия​

На фазе 1-2 (no Kazakhstan datacenter):

  • казахстанских конечных клиентов обслуживают через partners-residents (партнёр становится data controller в Казахстане, handles локальное хранение через свою инфраструктуру);
  • vitrip.store сайт не targets казахстанскую аудиторию напрямую как B2C-канал в этой фазе;
  • partner agreements explicit о cross-border transfer Kazakhstan → EU данных partner customers.

На фазе 3-4:

  • option: Vitiana datacenter в Казахстане через OVHcloud (если будет local presence) или other provider (Kazakhstan-resident cloud);
  • option: partnership с Kazakhstan-resident company (joint venture или licensing) для local data handling;
  • option: stay в текущей model через partners — если Kazakhstan B2C scope не значительный.

Open question — развилка с пользователем. Эскалируется при подходе к фазе 3.

8.3. Cross-border transfer mechanisms​

Реализация см. раздел 3.8.

Часть 9. Compliance в operational layer​

9.1. Compliance dashboards​

Internal Operational Surface:

  • DSR queue dashboard (open requests, SLA tracking);
  • breach incidents dashboard;
  • DPIA registry status;
  • sub-processor changes pending notifications;
  • AML alerts queue;
  • partner KYC re-verification due dates;
  • TOMS calculation anomalies.

DPO dedicated dashboard:

  • aggregated view всех compliance metrics;
  • DSR statistics;
  • breach response status;
  • audit log access logs;
  • pending compliance reviews.

9.2. Compliance alerts​

  • DSR SLA approaching (28 days into 30-day window);
  • breach detected (immediate alert);
  • AML pattern detected (immediate alert to compliance team);
  • sub-processor change requires approval;
  • DPIA review due (annual cycle);
  • insolvency protection expiry approaching (60-day warning);
  • partner KYC expiring (90-day warning).

9.3. Compliance audits​

Internal:

  • quarterly compliance review;
  • annual DPIA review всех existing processes;
  • annual sub-processor list audit;
  • annual AML/KYC processes audit.

External:

  • annual independent privacy audit (фаза 3+);
  • SOC 2 Type II certification (фаза 4 — Enterprise tier requirement);
  • ISO 27001 certification (фаза 4);
  • PCI DSS Self-Assessment Questionnaire (annual);
  • specific tenant audits (Enterprise tier — могут требовать).

Часть 10. Compliance в API as Product​

Compliance — часть продуктовой ценности для партнёров. Партнёр интегрируется с Vitiana и получает compliance "out of the box" в значительной мере.

10.1. Compliance documents в Partner Console​

  • DPA (signed copy);
  • sub-processor list (current);
  • transparency reports (annual);
  • privacy policy (current and historical versions);
  • T&C (current and historical versions);
  • compliance certifications (когда получены — SOC 2, ISO 27001).

10.2. Compliance API endpoints​

  • DSR submission API (для партнёров, желающих интегрировать DSR в свой UI);
  • DSR status check API;
  • consent record API (для партнёров — sync consent с Vitiana);
  • audit log export API (для партнёров — own audit purposes).

10.3. Compliance в developer portal​

  • compliance documentation section;
  • best practices guide для партнёров handling shared compliance responsibilities;
  • DPA template (downloadable, signable);
  • code samples для DSR integration, consent capture, breach notification webhooks.

Часть 11. Связь с другими доменами второго слоя​

11.1. Влияние на commercial-model​

См. reference/commercial-model.md. Compliance влияет на:

  • TOMS VAT calculation в маржинальной модели;
  • VAT rates per юрисдикция;
  • DAC7 reporting threshold (€2000+ or 30+ transactions per seller per year);
  • consumer protection cancellation/refund rules;
  • Package Travel Directive substitution и compensation rules.

11.2. Влияние на partner-finance-and-clearing​

См. reference/partner-finance-and-clearing.md. Compliance влияет на:

  • AML/KYC procedures как часть partner onboarding;
  • transaction monitoring для AML purposes;
  • suspended/blocked partner workflow при KYC issues;
  • tax IDs storage и validation для DAC7 reporting.

11.3. Влияние на post-booking-lifecycle​

См. reference/post-booking-lifecycle.md. Compliance влияет на:

  • refund timing (PSD2 — 14-day standard for non-card refunds; specific rules для package travel);
  • substitution workflows (Package Travel Directive);
  • compensation calculation (Package Travel Directive);
  • cancellation rules (Consumer Rights Directive + Package Travel Directive overrides).

11.4. Влияние на tour-builder-domain​

См. reference/tour-builder-domain.md + будущий tour-builder-operational-model.md. Compliance влияет на:

  • module classification (tourist services intrinsic / significant);
  • auto-detection package travel при composition;
  • pre-contractual information generation;
  • drift detection и significant changes notification;
  • insolvency protection requirement при packaging.

11.5. Влияние на tenancy-and-identity и tenant-configuration​

См. reference/tenancy-and-identity.md и reference/tenant-configuration-and-enablement.md. Compliance влияет на:

  • merchant-of-record model storage;
  • DPA registry per tenant;
  • KYC status per tenant;
  • insolvency protection registry per tenant;
  • tax residence per tenant;
  • data residency preferences per tenant.

11.6. Влияние на data-platform-and-events-tracking, ml-platform​

См. overview/data-and-intelligence-spine.md и будущие reference/data-platform-and-events-tracking.md, reference/ml-platform.md. Compliance влияет на:

  • privacy classes per data field;
  • purpose limitation enforcement;
  • anonymization at capture для analytical events;
  • automated decision-making transparency;
  • explainable AI для critical models;
  • DPIA для new ML use cases.

11.7. Влияние на storage и database-schema​

См. reference/storage.md и reference/database-schema.md. Compliance влияет на:

  • privacy class fields в schema;
  • retention policies per category;
  • audit log как separate retention-grade storage class;
  • tombstone pattern для erasure;
  • encryption at rest baseline.

Часть 12. Развилки и открытые вопросы​

12.1. Юридическая резиденция Vitiana​

Открытый вопрос: где регистрируется юридическое лицо Vitiana?

Влияние:

  • VAT residence для TOMS;
  • DAC7 reporting authority;
  • DPA jurisdiction;
  • corporate tax;
  • ease of doing business;
  • partnerships with EU partners.

Возможные варианты:

  • Чехия (EU-residence, преимущества TOMS, simplified DAC7 reporting в одной EU-стране, но более сложная VAT registration в multiple EU stranger);
  • Польша (аналогично Чехии);
  • Украина (UA-residence, без TOMS обязательств, но usage Ukrainian Hryvnia как functional currency, additional sanctions risks);
  • Кипр / Мальта (EU + tax-friendly, popular для tech companies);
  • Ireland / Estonia (EU + e-residency или tech-friendly).

Рекомендация архитектора: при дизайне платформы поддерживать flexibility для смены резиденции в первые 12 месяцев. Optimal — Чехия или Польша для full EU-compliance defaults. Эскалируется к юристу + бизнес-стороне.

12.2. Partner с Моделью A — package travel organiser status​

Открытый вопрос: как точно определить, является ли partner package travel organiser в каждой конкретной booking?

Influences architecturally:

  • Tour Builder module classification rules;
  • Auto-detection logic в commercial flow;
  • Tenant Configuration — explicit organiser per product type.

Решение: поэтапно — на фазе 2 manual configuration per partner per product type; на фазе 3-4 auto-detection с governance review override.

12.3. Insolvency protection mechanism​

Открытый вопрос: какой mechanism insolvency protection использует Vitiana — страховой полис, банковская гарантия или escrow?

Стандартная практика: страховой полис у specialized travel insurer.

Эскалация: к юристу + insurance broker для оценки options и costs.

12.4. Kazakhstan localization​

Открытый вопрос: при росте Kazakhstan B2C scope — invest в Kazakhstan datacenter или работать через partners?

Эскалация: при подходе к фазе 3 на основе actual Kazakhstan revenue.

12.5. EU broader VLOP threshold​

Открытый вопрос: при росте к 45M+ EU monthly users — VLOP status и additional requirements.

Эскалация: при approach к fаse 4.

12.6. PSP выбор per юрисдикция​

Открытый вопрос: какой PSP в каждой стране первой волны (EU, UA, KZ)?

Эскалация: в документ payment-domain.md (создаётся следующим в Группе 1).

12.7. Туроператорская лицензия в Украине​

Открытый вопрос: при продаже tour packages в Украине через vitrip.store от своего имени — требуется ли туроператорская лицензия?

Эскалация: к украинскому юристу.

12.8. SOC 2 / ISO 27001 timing​

Открытый вопрос: SOC 2 Type II audit обычно требует 12 месяцев observation period; ISO 27001 — 6+ месяцев preparation. Когда начинать?

Рекомендация: preparation на фазе 3, achievement на фазе 4 при появлении первых Enterprise contracts требующих этих certifications.

Часть 13. Compliance roadmap по фазам​

Фаза 1 (0-12 мес) — Compliance baseline​

  • GDPR baseline implementation: privacy classes, DSR workflow (manual), consent management, audit log;
  • privacy policy + T&C published в multiple languages;
  • DPA template prepared;
  • sub-processor list initial published;
  • breach response playbook;
  • basic security baseline (encryption, access control, logging);
  • legal entity established (decision in this phase);
  • DPO informally identified (formal appointment in phase 2).

Фаза 2 (12-24 мес) — Compliance maturity для платных партнёров​

  • DSR Service automation;
  • Consent Management Service в production;
  • DPO formally appointed;
  • DPA Registry и Sub-processor Registry operational;
  • KYC procedure для partner certification;
  • AML monitoring basic implementation;
  • TOMS calculation в commercial flow;
  • Pre-contractual Information Generator в Tour Builder;
  • Insolvency protection в place;
  • DPIA workflow;
  • Transparency reports baseline для DSA.

Фаза 3 (24-36 мес) — Compliance production-grade​

  • automated DSR Service с 7-day SLA;
  • ML-driven anomaly detection в AML monitoring;
  • annual independent privacy audit;
  • DAC7 reporting automation (если EU-resident);
  • DSA full compliance (notice-and-action, complaint handling, recommender explanation);
  • DPIA для каждого new ML use case;
  • compliance API endpoints в Partner Console;
  • multi-region data handling preparation.

Фаза 4 (36+ мес) — Enterprise compliance​

  • SOC 2 Type II certification;
  • ISO 27001 certification;
  • multi-region data residency для Enterprise tenants;
  • VLOP assessment если applicable;
  • Kazakhstan datacenter (если decision to invest);
  • specific tenant audits supported.

Связанная документация​

Опорные документы первого слоя​

Связанные документы второго слоя​

Документы развития​