Аудитория: 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
Revolving-линия
Это основной тип линии. По мере погашения использованных сумм лимит восстанавливается и снова становится доступным. У каждого отдельного drawdown есть свой срок возврата, например 45 дней. Сама линия остается активной до даты истечения или до отдельного решения о ее закрытии.3. Ограничения кредиторов: eligibility matrix
У разных кредиторов разный уровень толерантности к риску. Treasury-модуль позволяет платформе задавать, какие средства каких кредиторов нельзя использовать для финансирования конкретных merchants. Примеры ограничений:
Эти правила применяются автоматически каждый раз, когда система принимает решение о финансировании batch-партии чеков.
4. Кредитный профиль merchant
Каждому merchant платформа присваивает кредитный профиль.
Кредитный рейтинг влияет на eligibility для funding. Консервативные lenders могут отказаться финансировать merchants с рейтингом C и ниже. Сам рейтинг управляется вручную командой finance.
Автоматическая блокировка при просроченном settlement
Если merchant не закрывает settlement дольше допустимого порога, по умолчанию это 3 дня, платформа автоматически:- Блокирует отгрузку новых batch-партий этому merchant
- Фиксирует сам факт блокировки и ее дату
- Уведомляет администратора instance
5. Агрегированный settlement-баланс
Платформа поддерживает единый пул ликвидности, то есть совокупность доступных средств по всем активным кредитным линиям.Структура счетов
Для управления распределением ликвидности между instances платформа использует внутреннюю структуру счетов:Platform pool (all credit lines) → Instance account A / Instance account B / Reserve account
CFO и COO могут вручную ребалансировать выделенные лимиты между instances через административный интерфейс. Это дает возможность гибко управлять ликвидностью, не меняя условия базовых кредитных линий.
6. Допустимый риск и стратегия аллокации
Когда batch-партия чеков отгружается merchant, система автоматически выбирает, какая кредитная линия должна ее профинансировать. Решение принимается на основе настроенной стратегии аллокации.
Помимо выбранной стратегии, система применяет жесткие ограничения по допустимому риску:
- Максимальная доля одного 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.
Ключевые метрики:
Если процентная ставка по кредитным линиям выше, чем доход от комиссий, платформа фактически субсидирует операции за счет собственных средств. На фазе роста это может быть приемлемо, если ситуация явно отслеживается и контролируется.
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
Инициатор финансовой операции и ее утверждающий должны всегда быть разными людьми. Система не должна позволять одному сотруднику в одиночку пройти весь цикл операции.Velocity limits
Лимиты на объем drawdowns из одной линии в день служат защитой от ошибок и злоупотреблений. Эти лимиты настраиваются отдельно для каждой линии.Уведомления
Система автоматически уведомляет finance и operations-команды о следующих событиях:11. Audit и compliance
Все операции записываются в неизменяемый audit log, включая:- кто выполнил действие и когда
- значения до и после
- IP-адрес и подтверждение дополнительной аутентификации
repaid или defaulted.
12. Этапы внедрения
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? Это может снизить стоимость фондирования.