> ## Documentation Index
> Fetch the complete documentation index at: https://whalescorp.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Краткое резюме по казначейству и кредитованию

> **Аудитория**: CFO, COO, владельцы платформы\
> **Цель**: согласовать мультивалютную модель кредитования, подход к допустимому кредитному риску и операционные процедуры\
> **Статус**: концепт на этапе ревью, до реализации\
> **Техническая документация**: `TREASURY.md`, для команды разработки

## 1. Зачем нужен treasury-модуль

Бизнес-модель платформы предполагает, что merchants берут batch-партии чеков **на реализацию** и рассчитываются с Issuer только после продажи чеков, обычно ежемесячно. Это означает, что между моментом отгрузки batch-партии merchant и моментом получения оплаты возникает разрыв финансирования до 30 дней.

Чтобы платформа продолжала работать без перебоев в этот период, требуется внешнее финансирование. Treasury-модуль как раз решает эту задачу: он привлекает кредитные линии от инвесторов и кредиторов и распределяет их на финансирование merchants в соответствии с заданным для платформы уровнем допустимого риска.

**Упрощенная модель:**

`Lenders → Credit lines → Platform → Merchant funding → Settlement → Repayment to lenders`

Платформа зарабатывает на спреде:

**доход от комиссий merchants − процентные расходы по кредитным линиям = чистый carry**

## 2. Кредиторы платформы

Источниками финансирования для платформы могут быть:

* Владельцы платформы и инвесторы, через прямые займы
* Внешние кредиторы: компании, фонды, частные лица
* В будущем - децентрализованные протоколы ликвидности, то есть DeFi

Каждый кредитор может открыть одну или несколько **кредитных линий** со своими индивидуальными условиями.

| Параметр | Описание |
| :- | :- |
| Валюта | USDC, USD, EUR, USDT, поддерживается мультивалютность |
| Тип | Revolving или term |
| Лимит | Максимальная сумма, доступная в рамках линии |
| Процентная ставка | Фиксированная или плавающая, например SOFR / EURIBOR + спред |
| Срок действия | Дата истечения линии |
| Обеспечение | На первом этапе без обеспечения |

### Revolving-линия

Это основной тип линии. По мере погашения использованных сумм лимит восстанавливается и снова становится доступным. У каждого отдельного drawdown есть свой срок возврата, например 45 дней. Сама линия остается активной до даты истечения или до отдельного решения о ее закрытии.

## 3. Ограничения кредиторов: eligibility matrix

У разных кредиторов разный уровень толерантности к риску. Treasury-модуль позволяет платформе задавать, **какие средства каких кредиторов нельзя использовать для финансирования конкретных merchants**.

Примеры ограничений:

| Ограничение | Пример |
| :- | :- |
| Минимальный кредитный рейтинг merchant | Консервативный кредитор финансирует только merchants с рейтингом A или B |
| Исключение instance | Кредитор не хочет экспозиции к конкретному рынку, например отдельной стране |
| Эксклюзивность instance | Кредитор работает только с одним конкретным партнером |
| Лимит на merchant | Не более \$5,000 из одной линии на одного merchant |
| Лимит на instance | Не более 30% линии может быть распределено на один instance |

Эти правила применяются автоматически каждый раз, когда система принимает решение о финансировании batch-партии чеков.

## 4. Кредитный профиль merchant

Каждому merchant платформа присваивает **кредитный профиль**.

| Параметр | Описание |
| :- | :- |
| Кредитный лимит | Максимальный объем открытых batch-партий в любой момент |
| Текущая экспозиция | Сумма по уже отгруженным, но еще не оплаченным batch-партиям |
| Кредитный рейтинг | A / B / C / D, назначается вручную |
| Срок settlement | Стандартно 30 дней, параметр настраивается |
| Предпочтительная валюта settlement | Валюта, в которой merchant рассчитывается |

**Кредитный рейтинг** влияет на eligibility для funding. Консервативные lenders могут отказаться финансировать merchants с рейтингом C и ниже. Сам рейтинг управляется вручную командой finance.

### Автоматическая блокировка при просроченном settlement

Если merchant не закрывает settlement дольше допустимого порога, по умолчанию это 3 дня, платформа автоматически:

1. Блокирует отгрузку новых batch-партий этому merchant
2. Фиксирует сам факт блокировки и ее дату
3. Уведомляет администратора instance

Разблокировка выполняется только вручную и требует подтверждения администратора.

## 5. Агрегированный settlement-баланс

Платформа поддерживает единый **пул ликвидности**, то есть совокупность доступных средств по всем активным кредитным линиям.

### Структура счетов

Для управления распределением ликвидности между instances платформа использует внутреннюю структуру счетов:

`Platform pool (all credit lines) → Instance account A / Instance account B / Reserve account`

CFO и COO могут **вручную ребалансировать выделенные лимиты** между instances через административный интерфейс. Это дает возможность гибко управлять ликвидностью, не меняя условия базовых кредитных линий.

## 6. Допустимый риск и стратегия аллокации

Когда batch-партия чеков отгружается merchant, система автоматически выбирает, какая кредитная линия должна ее профинансировать. Решение принимается на основе настроенной **стратегии аллокации**.

| Стратегия | Логика | Когда использовать |
| :- | :- | :- |
| Currency match | Использовать линию в валюте settlement merchant | Чтобы убрать FX risk |
| Lowest cost | Использовать линию с минимальной процентной ставкой | Чтобы минимизировать стоимость фондирования |
| Maturity match | Использовать линию, срок действия которой перекрывает срок settlement merchant | Чтобы избежать несоответствия сроков |
| Maximum availability | Использовать линию с наибольшим свободным остатком | Чтобы быстрее развернуть ликвидность |
| Balanced | Равномерно распределять использование между всеми линиями | Чтобы снизить зависимость от одного источника |

Помимо выбранной стратегии, система применяет **жесткие ограничения по допустимому риску**:

* Максимальная доля одного merchant в общем пуле, например не более 20%
* Максимальная загрузка одной кредитной линии, например не более 40%
* Максимальное отношение долга к капиталу
* Минимальный оставшийся срок действия линии, при котором ее еще можно использовать

## 7. FX risk

Платформа работает сразу с несколькими валютами. Когда валюта credit line отличается от settlement currency merchant, платформа **берет на себя FX risk**.

**Политика:** FX risk учитывается явно и отражается в отчетности. Для каждого drawdown из линии в иностранной валюте курс фиксируется на дату транзакции. Во время settlement фактическая прибыль или убыток от курсовой разницы отражается в отчете carry P\&L.

На первом этапе хеджирование не планируется. Рекомендуемый подход - отдавать приоритет стратегии **currency match**, чтобы минимизировать открытую валютную экспозицию.

## 8. Экономика treasury и carry P\&L

Платформа зарабатывает на **спреде** между merchant income и стоимостью funding.

| Показатель | Описание |
| :- | :- |
| **Доход** | Merchant fees, то есть issuance, redemption и exchange |
| **Расход** | Проценты по кредитным линиям |
| **FX differences** | Прибыль или убыток из-за currency mismatch |
| **Net carry** | Доход минус расходы |

**Ключевые метрики:**

| Метрика | Значение |
| :- | :- |
| Cost of funds | Годовая ставка по всему портфелю кредитных линий |
| Fee yield | Процентная доходность, генерируемая объемом merchant-транзакций |
| Net spread | Разница между fee yield и cost of funds |
| Average settlement term | Среднее число дней от отгрузки до settlement |
| Overdue settlement ratio | Доля общего объема, находящаяся в просрочке |
| Pool utilization | Доля общего доступного лимита, которая уже используется |

Если процентная ставка по кредитным линиям выше, чем доход от комиссий, платформа фактически субсидирует операции за счет собственных средств. На фазе роста это может быть приемлемо, если ситуация явно отслеживается и контролируется.

## 9. Управление рисками

### Риск ликвидности, maturity mismatch

Ситуация: кредитная линия истекает раньше, чем merchant завершает settlement.

Контроль: система находит такие проблемные drawdown-операции и показывает их сумму в дашборде. Если несоответствие сроков существует, CFO получает уведомление.

### Кредитный риск merchant

Ситуация: merchant не платит.

Контроль: автоматическая блокировка новых batch-партий при overdue settlement, ручное понижение credit rating, управление со стороны COO.

### Риск концентрации

Ситуация: слишком большая часть пула ликвидности сконцентрирована на одном merchant или на одной линии.

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

### FX risk

Ситуация: курс меняется между моментом drawdown и settlement.

Контроль: явный учет, отражение в carry P\&L и приоритет стратегии currency match.

## 10. Операционные контроли

### Принцип four-eyes

Инициатор финансовой операции и ее утверждающий должны **всегда быть разными людьми**. Система не должна позволять одному сотруднику в одиночку пройти весь цикл операции.

| Операция | Инициатор | Утверждает |
| :- | :- | :- |
| Ручной drawdown из кредитной линии | Finance | Другой участник Finance-команды или Administrator |
| Крупный drawdown, выше порога | Finance / Administrator | Только Owner |
| Закрытие кредитной линии | Finance / Administrator | Owner |
| Изменение risk appetite | Finance / Administrator | Owner |
| Ребалансировка внутренних счетов | Finance | Administrator / Owner |

### Velocity limits

Лимиты на объем drawdowns из одной линии в день служат защитой от ошибок и злоупотреблений. Эти лимиты настраиваются отдельно для каждой линии.

### Уведомления

Система автоматически уведомляет finance и operations-команды о следующих событиях:

| Событие | Получатель |
| :- | :- |
| Credit line истекает через N дней | CFO, Finance |
| Загрузка линии превысила 80% | CFO, Finance |
| Линия истекает при наличии непогашенного долга | CFO, срочно |
| Выполнен автоматический drawdown | Finance, сводно или сразу |
| Крупный drawdown | CFO, Finance |
| Merchant заморожен из-за просроченного settlement | Instance Administrator |

## 11. Audit и compliance

Все операции записываются в неизменяемый audit log, включая:

* кто выполнил действие и когда
* значения до и после
* IP-адрес и подтверждение дополнительной аутентификации

Финансовые записи, такие как drawdowns, начисление процентов и allocations, **нельзя изменить или удалить** после создания. Их можно только перевести в финальный статус, например `repaid` или `defaulted`.

## 12. Этапы внедрения

| Этап | Объем | Приоритет |
| :- | :- | :- |
| **Phase 1** | Реестр кредиторов, credit lines, eligibility matrix | P0 — foundation |
| **Phase 2** | Merchant credit profiles, allocation engine, automatic drawdown | P0 — core functionality |
| **Phase 3** | Начисление процентов, carry P\&L | P1 |
| **Phase 4** | Dashboard settlement-баланса, уведомления, мониторинг просрочек | P1 |
| **Phase 5** | Редактор прав по функциям | P2 |

## 13. Открытые вопросы для согласования

**13.1 Первые кредиторы**\
Кто станет первыми кредиторами платформы? Какие условия ожидаются: валюта, ставка, лимит, срок?

**13.2 Кредитные лимиты merchant**\
Каким должен быть стандартный лимит для нового merchant? По каким критериям он должен увеличиваться? Нужен ли многоступенчатый процесс утверждения выше определенного порога?

**13.3 Стратегия аллокации по умолчанию**\
Какая стратегия должна использоваться по умолчанию? Рекомендация: **currency match**, чтобы минимизировать FX risk.

**13.4 Порог для крупных операций, four-eyes**\
Начиная с какого размера drawdown должно требоваться одобрение Owner, а не только Finance? В черновой документации заложено значение **\$10,000 USDC**, но оно еще требует подтверждения.

**13.5 Валюта merchant settlement**\
Какие валюты будут приниматься для merchant settlement? Кто несет FX risk при конвертации? Нужна ли мультивалютная аллокация с первого дня, или на старте достаточно линий на базе USDC?

**13.6 Политика просрочек: автоматический или ручной контроль**\
Сейчас предполагается автоматическая блокировка после более чем 3 дней просрочки. Нужны ли разные пороги для разных категорий merchant? Какой должен быть процесс урегулирования после срабатывания блокировки?

**13.7 Стоимость фондирования против дохода от комиссий**\
Покрывают ли merchant fees стоимость внешнего фондирования при текущей pricing-модели? Нужно ли проводить финансовое сценарное моделирование до запуска?

**13.8 Обеспечение для кредиторов**\
На начальном этапе линии будут без обеспечения. При каком размере портфеля имеет смысл перейти к структуре receivables assignment? Это может снизить стоимость фондирования.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.