Політика електронних доказів та зберігання INBULK

1. Мета і статус

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

1.2. Політика не встановлює наперед доказову силу в конкретному суді чи арбітражі. Остаточна оцінка здійснюється відповідно до застосовного процесуального права.

1.3. У разі суперечності перевагу має Договір приєднання та незмінювана редакція умов конкретної операції.

2. Об’єкти доказування

2.1. Доказуванню можуть підлягати:

• особа, компанія, роль і Права на момент дії;
• зміст і редакція Ордера, Заявки, Замовлення, Угоди / Business, Контракту або документа;
• факт, спосіб, дата й час Підписання або Акцепту;
• джерело, зміст і час зовнішньої або автоматизованої події;
• формування, передання, отримання, перегляд, відмова, помилка або скасування;
• статус виконання, оплати, логістики, забезпечення, страхування чи фінансування;
• історія змін, повідомлень, претензій та заходів безпеки.

3. Класифікація доказів

3.1. Доказ класифікується за рівнем підтвердження:

3.2. Загальний статус «верифіковано» без зазначення об’єкта, scope, джерела і дати не повинен використовуватися як доказ конкретної обставини.

4. Джерела

4.1. Джерелами електронних доказів є:

• системні журнали Платформи;
• незмінювані snapshot Ордера, Заявки, Замовлення та legal bundle;
• підписані документи й Доказова база підписання;
• API-запити, webhooks, idempotency keys та response logs;
• банківські, платіжні, TSP, KYC/KYB, телематичні, складські, лабораторні та інші інтеграції;
• завантажені оригінали, електронні документи, копії, фото і скани;
• email, повідомлення, чати та support records;
• акти, сертифікати, транспортні, вагові, митні та страхові документи.

5. Операційний статус і юридичний факт

5.1. Операційний статус, GPS, фото, вручну внесена вага, повідомлення водія, файл або скан самі по собі не підтверджують остаточне виконання, кількість, якість, право власності, ризик або платіж, крім випадку, прямо визначеного умовами операції та відповідною інтеграцією.

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

5.3. Проєкт або автоматично сформований документ не є належно оформленим документом до Підписання чи іншого передбаченого оформлення.

6. Версії та незмінність

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

6.2. Зміна істотних умов створює нову редакцію. Попередня редакція не видаляється й не може бути підмінена в доказовому пакеті.

6.3. Підтвердження Угоди / Business або Замовлення повинно посилатися на конкретну редакцію Ордера чи Заявки й системну подію, яка створила операцію.

7. Час і послідовність подій

7.1. Системні події зберігаються в UTC; інтерфейс може показувати локальний час. Джерело часу та, якщо застосована, електронна позначка часу фіксуються.

7.2. Системний час підтверджує час системної події, але не називається кваліфікованою позначкою часу без відповідної послуги.

7.3. Повторне надсилання того самого запиту з тим самим ключем ідемпотентності (idempotency key) не створює повторної операції. Історія повторних спроб виконання такого запиту фіксується та зберігається в системних журналах.

8. Пакет електронних доказів

8.1. Для підтвердження юридично значущої дії або події Платформа може формувати пакет електронних доказів, який залежно від виду операції може містити:

• ідентифікатори операції та документа, його редакцію і криптографічний відбиток (хеш);
• відомості про сторони, Підписанта або Авторизованого користувача та його повноваження на момент вчинення дії;
• остаточні умови операції та редакції документів, прийняті Користувачем;
• спосіб автентифікації та електронного підписання, а також результати відповідних перевірок;
• дату і час події та необхідні технічні дані;
• історію прийняття, підписання, доставки та зміни статусів;
• електронні сертифікати, позначки часу та підтвердження сторонніх постачальників, якщо вони застосовувалися;
• інші системні записи, необхідні для підтвердження відповідної дії або події.

8.2. Склад пакета визначається характером операції, застосованими засобами автентифікації та підписання і фактично зафіксованими даними.

8.3. Пакет не повинен містити тверджень про перевірку або підтвердження факту, якщо така перевірка фактично не проводилася або її результат не був належним чином зафіксований.

9. Зберігання

9.1. Строк визначається видом документа, договором, правом, позовною давністю, податковими й бухгалтерськими вимогами, претензіями, страхуванням і ризиком.

9.2. Підписані Контракти, Підтвердження Угод, Замовлення, платіжні та security evidence зберігаються щонайменше протягом строку відкритих зобов’язань і потенційних вимог.

9.3. Резервні копії зберігаються та видаляються відповідно до встановленого циклу резервного копіювання і строків зберігання. Якщо на відповідні дані поширюється обов’язок їх збереження для цілей спору, розслідування, аудиту або виконання вимог законодавства (legal hold), їх видалення призупиняється на строк дії такого обов’язку. Дані, відновлені з резервної копії, надалі обробляються відповідно до чинних правил зберігання та видалення.

10. Збереження даних у зв’язку з правовими вимогами (legal hold)

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

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

11. Експорт і доступ

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

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

11.3. Перед закриттям Облікового запису Користувачу надається розумна можливість завантажити доступні документи, якщо інше не вимагається законом або безпекою.

12. Виправлення помилок

12.1. Помилкова подія не видаляється безслідно. Вона скасовується або коригується новою подією з посиланням, причиною, автором і часом.

12.2. Адміністратор не має права змінювати заднім числом зміст Акцептованого Ордера, підписаного документа або пов’язаних із ними електронних доказів без збереження повної історії таких змін.

13. Інциденти та ланцюг збереження

13.1. У разі інциденту Оператор зберігає необхідні журнали, файли, системні дані та інформацію про доступ для його розслідування.

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

14. Зміни

14.1. Для кожної операції застосовується редакція Політики, зафіксована відповідним legal bundle або умовами. Матеріальні зміни не мають ретроспективної дії.

15. Контакти

15.1. Питання щодо цієї Політики — [email protected].

16. Прикінцеві положення

16.1. Ця Політика є самостійним публічним документом INBULK.COM та застосовується до електронних доказів і даних, що формуються або зберігаються під час використання Платформи.

16.2. Якщо для окремої юрисдикції законодавством встановлено спеціальні вимоги до електронних доказів або строків їх зберігання, застосовуються відповідні обов’язкові вимоги такої юрисдикції.

Історія редакцій