# 07. Информация о депоненте (хранителе отчётов)

**Источник:** ЗАО «Уайт Бёрд»
**Размер:** 351 КБ, 1 стр.
**Юр.основание:** абз. 4 п. 18 Правил деятельности оператора криптоплатформы ПВТ

## Что это
Whitebird обязан **ежедневно** отправлять третьему лицу полные отчёты по каждому клиенту (балансы, исполненные/неисполненные ордера, остатки криптовалют). Это документ, объявляющий имя и реквизиты этого третьего лица — депонента.

## Депонент
| Поле | Значение |
|---|---|
| Юр.лицо | ООО «А1 цифровые сервисы» |
| УНП | 193495076 |
| Юр.адрес | 220031 Минск, ул. Танковая, д.11, каб. 209А |
| Почтовый адрес | 220030 Минск, ул. Интернациональная, 36-2 |
| Телефон | +375 29 600-02-25 |
| E-mail | sales@a1digital.by |

## Что подлежит ежедневному депонированию
1. **По каждому клиенту**, участвовавшему в торгах в отчётный день:
   - Сумма / остаток денежных средств на банковских счетах Компании
   - Количество / остаток электронных денег
   - Остатки криптовалют в виртуальных кошельках Компании
2. **Все ордера за день:**
   - Исполненные заявки (покупка / продажа / обмен токенов)
   - Неисполненные заявки

## Моё мнение
**Это самый сильный регуляторный аргумент ПВТ-режима.** Ежедневная депонирование клиентских балансов третьей стороне = биржа физически не может «спрятать» дыру в балансе. Это de-facto Proof of Reserves + Proof of Liabilities, но не через blockchain attestation, а через гос. регулируемое архивирование.

Это особенно важно после кейсов **FTX, Mt.Gox, QuadrigaCX** — каждая из этих катастроф произошла потому что не было обязательной third-party reconciliation. В ПВТ-режиме такая модель невозможна юридически.

**Выбор депонента — А1 цифровые сервисы:** это дочка А1 Беларусь (бывший Velcom, австрийский А1 Telekom). Один из крупнейших IT-операторов РБ. Хорошее имя, плюс А1 имеет дата-центры уровня Tier III. Логичный выбор.

**Странность:** один депонент = single point of failure. Если А1 цифровые сервисы потерпит сбой / закроется / будет скомпрометирован — Whitebird нарушает п. 18. Лучше иметь мульти-депонент или blockchain-anchored solution.

## Что нужно команде Монтаны для копирования 1:1
1. **Договор с депонентом отчётов** — обязательный, аналог А1. Кандидаты:
   - **В РБ:** А1 цифровые сервисы / beCloud / hoster.by (если копируем ПВТ-модель).
   - **В ЕС:** licensed cloud archive providers (Amazon S3 Glacier with compliance, hoster.by, Iron Mountain).
   - **Web3:** Filecoin / Arweave / Storj — для immutable архива клиентских отчётов.
2. **Внутренний модуль daily_depository_export:**
   - Cron-задача в 00:00 UTC: snapshot всех client balances + ордер-журнал за день.
   - Подпись HMAC-SHA-256 или Ed25519 от приватного ключа Монтаны.
   - Шифрование AES-256-GCM (асимметричный ключ депонента).
   - Отправка по SFTP / API депонента + локальная архивация.
   - Получение acknowledgement / signed receipt от депонента.
3. **Содержание snapshot:**
   ```json
   {
     "date": "2026-05-16",
     "node": "montana-frankfurt",
     "clients": [
       {
         "user_id": "...",
         "balances": {
           "BYN": "0.00",
           "USDT": "1234.567890",
           "BTC": "0.05312000"
         },
         "orders_filled": [...],
         "orders_open": [...]
       }
     ],
     "total_aum": {...},
     "signature": "..."
   }
   ```
4. **Blockchain anchor (Montana-specific):** дополнительно к классическому депоненту — хэш ежедневного snapshot записывается в нашу TimeChain или в Bitcoin как Merkle root. Это позволяет клиенту независимо верифицировать, что его баланс был в общей сумме AUM на дату X.
5. **Public Proof of Reserves dashboard** — раздел на сайте, показывающий suma AUM по каждой монете, сравнивающий с on-chain reserves. Обновление 1 раз в сутки, синхронно с депонированием.
6. **Multi-jurisdiction:** для каждой юрисдикции свой депонент (РБ → А1; Литва → Bank of Lithuania reporting; ОАЭ → VARA reporting).

## Гэп с EU MiCA
MiCA Article 70 требует:
- **Segregation of client funds** — отдельные счета (Whitebird это и так делает)
- **Daily reconciliation** — у Whitebird ежедневно, что соответствует
- **External auditor annual** — у Whitebird не требуется ПВТ ежедневно, но годовой аудит есть

Итог: модель Whitebird **превосходит MiCA по частоте отчётности**, и должна легко пройти MiCA-CASP при адаптации к EU юрисдикции.

## Ссылки внутри Whitebird-стека
- → #04 (уведомление о рисках — общая обвязка)
- → #25, #28 (политики обработки персональных данных, отчёты)
- → #33 (Whitebird Report RUS — annual financials)