Перейти к содержанию

10. Поток денег: куда они приходят, куда уходят и где «лежат»

Этот документ отвечает на простой бизнес-вопрос: «когда клиент пополняет кошелёк или платит мерчанту — что физически происходит с деньгами и как это отражается в нашей внутренней бухгалтерии?». Документ написан для финансового отдела, продактов, бухгалтера, комплайнс-офицера и любого, кому нужно понимать движение средств в OneWallet «по-человечески» — без кода, без TigerBeetle-терминов, без SQL. Технические детали живут в dev-документации, ссылки на которую даны в самом конце.

1. Главная мысль на одной странице

OneWallet — это не «хранилище денег». OneWallet — это учётная книга, в которой записывается, кому из клиентов сколько мы должны. Реальные деньги физически лежат не у нас в офисе, а на наших банковских счетах и на корреспондентских счетах у платёжных партнёров.

Чтобы у бухгалтерии всегда сходился баланс, мы используем двойную запись: каждая операция оставляет след сразу на двух (или более) счетах. Если на одном счёте «прибавилось» — на другом ровно столько же «убавилось». Это закон бухгалтерии, а не наше изобретение и не вопрос выбора инструмента.

Внутри книги есть несколько категорий счетов:

  • Кошельки клиентов и бизнес-партнёров — обязательства системы перед людьми и компаниями. То, что клиент видит как «свой баланс».
  • Транзитные счета — служебные «коридоры», через которые проходят деньги во время многошаговых операций. После операции на них всегда ровно ноль.
  • Nostro-счета — зеркало наших реальных денег у внешних партнёров (банк, шлюз PromptPay). Должны сходиться с реальным банковским балансом до сатанга.
  • Счёт выручки — копилка комиссий, которые система оставляет себе.
  • Equity-счёт — «затыкающий» счёт, который трекает суммарный внешний поток (сколько денег вошло в систему минус сколько вышло).

Дальше — каждая категория подробно, с диаграммами для трёх ключевых сценариев: пополнение, вывод, перевод между клиентами.

2. Карта счетов OneWallet

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

2.1 Кошельки клиентов

  • Технический идентификатор: user.<id>.THB.
  • Это «личный карман» каждого клиента. Сумма на этом счёте — то, что клиент видит в мобильном приложении как «доступный баланс».
  • Не может уйти в минус: клиент не может потратить больше, чем имеет.
  • Деньги на кошельке — это наше обязательство перед клиентом. С точки зрения бухгалтерии: «мы должны клиенту X батов».

2.2 Кошельки мерчантов и агентов

  • Технические идентификаторы: merchant.<id>.THB, agent.<id>.THB, плюс отдельные *.settlement.THB для выплат.
  • Аналог клиентского кошелька, но для бизнес-партнёров. Сюда падают выручка магазина, поступления от QR-инвойсов, NFC-оплат, мини-аппов.
  • С точки зрения бухгалтерии — также наше обязательство: деньги принадлежат мерчанту, мы их держим у себя в книге до момента выплаты на его реальный банковский счёт.

2.3 Транзитные счета

  • Технический идентификатор: system.transit.<channel>.THB. Каналы — внутренний P2P, IPPS, мерчантский, инвойсный, служебный.
  • Это «коридоры», а не «комнаты». Деньги через них проходят, но никогда не остаются.
  • Главный финансовый инвариант OneWallet:

    Сумма по всем транзитным счетам всегда равна нулю.

  • Если хоть на одном транзите остался ненулевой остаток — это инцидент, на который немедленно срабатывает алерт.

2.4 Nostro — реальные деньги у партнёров

  • Технические идентификаторы:
  • system.nostro.bank.THB — деньги, физически лежащие на нашем банковском счёте в Таиланде.
  • system.nostro.ipps.THB — деньги, лежащие у нас на корсчёте у шлюза PromptPay / IPPS.
  • Каждый Nostro-счёт — это зеркало реального счёта в реальном банке или у реального партнёра. Цифра на Nostro обязана совпадать с цифрой на банковской выписке. Если расходятся — это инцидент.
  • Эти счета не растут «сами по себе»: они меняются только когда деньги физически приходят к партнёру (пополнение) или уходят от партнёра получателю (вывод, оплата мерчанту через PromptPay).

2.5 Счёт выручки

  • Технический идентификатор: system.revenue.THB.
  • Сюда оседают все комиссии, которые система удержала с операций клиентов и мерчантов.
  • Растёт постоянно, в зависимости от объёма операций. Это доход OneWallet — то, что мы заработали и оставили в системе.

2.6 Equity — «внешний мир» в одной строке

  • Технический идентификатор: system.equity.THB.
  • Это самый необычный счёт. Он играет роль затыкающего: его задача — «уравновесить» бухгалтерию каждый раз, когда деньги пересекают границу системы (входят извне или уходят наружу).
  • На любое пополнение со стороны клиента (через банк, через PromptPay) система делает запись: «деньги пришли извне → equity дал их нам». На любой вывод: «equity получил их обратно от нас».
  • Equity может уходить в минус — это нормально и заложено в конструкцию. Отрицательное значение equity означает «мы суммарно приняли от внешнего мира больше, чем отдали ему». Положительное — «мы отдали наружу больше, чем приняли».
  • Бухгалтер читает equity как «капитал, привнесённый внешним миром в систему» — это устоявшаяся бухгалтерская роль такого счёта.

Аналогия: представьте, что у вашего магазина есть касса (Nostro) и тетрадка, где вы записываете «я должен Васе 100 батов, я должен Маше 50» (кошельки клиентов). Equity — это строка в конце тетрадки «всего я принял в кассу извне 2 000, а выдал наружу 500». Она нужна, чтобы бухгалтерия сошлась.

3. Поток внутрь системы: пополнение кошелька (QP_TOPUP)

Это сценарий, когда деньги физически попадают в OneWallet из внешнего мира.

Бизнес-сценарий

Клиент Алиса хочет пополнить свой кошелёк на 1 000 THB. Она открывает приложение, выбирает «Пополнить с банковского счёта», подтверждает платёж в банковском приложении. Банк-партнёр переводит 1 000 THB на наш реальный банковский счёт. Шлюз пополнений видит подтверждение и говорит OneWallet: «зачисли Алисе 1 000 THB».

Что происходит в книге

flowchart LR
    subgraph EXT["Внешний мир"]
        BANK["Банк Алисы<br/>(реальный мир)"]
    end

    subgraph OW["OneWallet — внутренняя книга"]
        EQ["system.equity.THB<br/><i>(затыкающий счёт)</i>"]
        NOS["system.nostro.bank.THB<br/><i>(наш счёт в банке-партнёре)</i>"]
        TR["system.transit.IPPS.THB<br/><i>(коридор)</i>"]
        WAL["user.Алиса.THB<br/><i>(кошелёк клиента)</i>"]
    end

    BANK == "1. 1 000 THB<br/>физический перевод" ==> NOS
    EQ -- "2. запись: equity ↓<br/>1 000 THB" --> TR
    NOS -- "3. зеркало:<br/>nostro ↑ 1 000 THB" --> TR
    TR -- "4. зачисление<br/>1 000 THB" --> WAL

    classDef ext fill:#fee2e2,stroke:#dc2626
    classDef wallet fill:#e0f2fe,stroke:#0284c7
    classDef nostro fill:#fef9c3,stroke:#ca8a04
    classDef transit fill:#fef3c7,stroke:#d97706,stroke-dasharray: 4 2
    classDef equity fill:#ede9fe,stroke:#7c3aed
    class BANK ext
    class WAL wallet
    class NOS nostro
    class TR transit
    class EQ equity

Как это читать по-человечески

  1. Физически: банк-партнёр перевёл 1 000 THB на наш корпоративный счёт. На реальном банковском счёте OneWallet прибавилась тысяча.
  2. Бухгалтерская запись: equity «отдал» 1 000 THB в систему, Nostro «получил» (отразил то, что физически появилось в банке), и эти деньги через транзитный коридор зачислились на кошелёк Алисы.
  3. Транзит после операции снова в нуле — он своё дело сделал.
  4. Итог: у Алисы +1 000 THB, у нас в банке физически +1 000 THB, equity ушёл в минус на 1 000 (это нормально).

Что значит для бизнеса

  • Real money (то, что физически у нас лежит): выросло на 1 000.
  • Liability (то, что мы должны клиентам): выросло на 1 000.
  • Equity: уменьшился на 1 000 — это запомнили как «новые деньги пришли в систему извне».
  • Система осталась полностью сбалансирована: чему стало больше у партнёра — на столько же стало больше обязательств перед клиентом.

4. Поток наружу: вывод денег на внешний счёт (WITHDRAWAL / IPPS_WITHDRAWAL)

Это зеркальный сценарий: деньги физически уходят из OneWallet получателю.

Бизнес-сценарий

Клиент Алиса хочет вывести 800 THB на свой внешний банковский счёт. Она нажимает «Вывести», указывает реквизиты получателя. OneWallet списывает 800 THB с её кошелька и через IPPS-шлюз отправляет деньги получателю.

Что происходит в книге

flowchart LR
    subgraph OW["OneWallet — внутренняя книга"]
        WAL["user.Алиса.THB<br/><i>(кошелёк клиента)</i>"]
        TR["system.transit.IPPS.THB<br/><i>(коридор)</i>"]
        NOS["system.nostro.ipps.THB<br/><i>(наш корсчёт у шлюза)</i>"]
        EQ["system.equity.THB<br/><i>(затыкающий счёт)</i>"]
    end

    subgraph EXT["Внешний мир"]
        DEST["Банк получателя<br/>(реальный мир)"]
    end

    WAL -- "1. списание<br/>800 THB" --> TR
    TR -- "2. nostro ↓<br/>800 THB" --> NOS
    TR -- "3. equity ↑<br/>800 THB" --> EQ
    NOS == "4. физический перевод<br/>800 THB" ==> DEST

    classDef ext fill:#fee2e2,stroke:#dc2626
    classDef wallet fill:#e0f2fe,stroke:#0284c7
    classDef nostro fill:#fef9c3,stroke:#ca8a04
    classDef transit fill:#fef3c7,stroke:#d97706,stroke-dasharray: 4 2
    classDef equity fill:#ede9fe,stroke:#7c3aed
    class DEST ext
    class WAL wallet
    class NOS nostro
    class TR transit
    class EQ equity

Как это читать по-человечески

  1. Списали 800 THB с кошелька Алисы — её баланс упал.
  2. Через транзитный коридор «попросили» Nostro отдать эти 800 наружу.
  3. Equity получил «обратно» 800 THB — теперь, по бухгалтерии, мы меньше должны внешнему миру (или больше получили от него — смотря с какой стороны смотреть).
  4. Шлюз IPPS физически отправил 800 THB на банк получателя. На нашем корсчёте у шлюза стало на 800 меньше.

Что значит для бизнеса

  • Real money: уменьшилось на 800.
  • Liability: уменьшилось на 800 (мы больше не должны Алисе эти деньги).
  • Equity: вырос на 800 — это запомнили как «деньги ушли из системы наружу».
  • Бухгалтерия снова сошлась.

Замечание про оплату мерчанту через PromptPay (THAI_QR_PAY)

Сценарий, когда клиент сканирует PromptPay-QR в кафе и платит мерчанту, который не является клиентом OneWallet, — это тоже выход из системы, не внутренний перевод. С точки зрения денежного потока он структурно идентичен WITHDRAWAL: со счёта Алисы → через транзит → Nostro отдал → equity «вернул». Просто получатель — не банковский счёт самой Алисы, а торговая точка.

Если же мерчант — клиент OneWallet (например, использует наш инвойс или NFC-чек), деньги остаются внутри системы — это уже сценарий из §5.

5. Поток внутри системы: перевод между клиентами (P2P_TRANSFER)

Это сценарий, когда деньги не пересекают границу OneWallet. Они просто перемещаются между двумя счетами внутри нашей книги.

Бизнес-сценарий

Алиса переводит Бобу 500 THB. Оба — клиенты OneWallet. Комиссия системы — 1% (5 THB). Списываем с Алисы 505, Бобу зачисляем 500, 5 кладём себе в выручку.

Что происходит в книге

flowchart LR
    A["user.Алиса.THB<br/><i>(кошелёк отправителя)</i>"]
    T["system.transit.INTERNAL_P2P.THB<br/><i>(коридор)</i>"]
    B["user.Боб.THB<br/><i>(кошелёк получателя)</i>"]
    R["system.revenue.THB<br/><i>(копилка комиссий)</i>"]

    A -- "1. списание 505 THB" --> T
    T -- "2. зачисление 500 THB" --> B
    T -- "3. комиссия 5 THB" --> R

    classDef wallet fill:#e0f2fe,stroke:#0284c7
    classDef transit fill:#fef3c7,stroke:#d97706,stroke-dasharray: 4 2
    classDef revenue fill:#dcfce7,stroke:#16a34a
    class A,B wallet
    class T transit
    class R revenue

Как это читать по-человечески

  1. Алиса лишилась 505 THB.
  2. Боб получил 500 THB.
  3. Система удержала 5 THB как комиссию — они теперь в revenue.
  4. Транзитный коридор после операции снова в нуле: 505 пришло — 500 + 5 ушло.

Что значит для бизнеса

  • Real money (Nostro): не изменилось — никаких реальных денег в банк не уходило и не приходило, всё произошло «у нас в книге».
  • Liability (обязательства перед клиентами в сумме): не изменилась: Алиса должна на 505 меньше, Боб — на 500 больше, итого −5 (но на эти 5 у системы выросла выручка, см. ниже).
  • Equity: не изменился — внешний мир тут вообще не участвовал.
  • Revenue: вырос на 5 THB — это новый доход системы.

Где ещё применим этот же шаблон

Все эти типы операций тоже не пересекают границу системы и работают по той же логике (деньги между внутренними счетами + опциональная комиссия в revenue):

  • MINIAPP_CHARGE — клиент платит мини-приложению внутри OneWallet.
  • MINIAPP_CREDIT — мини-приложение возвращает деньги клиенту.
  • INVOICE_PAYMENT — клиент платит мерчанту по выставленному инвойсу.
  • NFC_CHARGE — клиент платит мерчанту прикладыванием браслета.
  • SERVICE_DEPOSIT — служебный модуль зачисляет клиенту деньги со служебного счёта.
  • ADMIN_TRANSFER — корректировка между внутренними счетами через админ-панель.

Все эти операции — это движение денег внутри книги; ни Nostro, ни equity не меняются. Меняются только внутренние строки книги (кошельки + revenue, если применяется комиссия).

6. Финансовые инварианты

Инвариант — это правило, которое обязано выполняться в любой момент. Если оно нарушено — это сразу инцидент, а не предмет для дискуссии.

Инвариант 1. Транзит в нуле

Сумма по всем транзитным счетам в любой момент времени равна нулю.

Это самое важное правило бухгалтерии OneWallet. Каждый транзит — это коридор: что туда вошло, обязано выйти. Если хоть на одном транзите остался ненулевой остаток после завершения операции — это значит, где-то деньги «зависли» или «потерялись». Это автоматически проверяется на каждом старте сервиса.

Инвариант 2. Что клиенты видят = чем мы располагаем

В любой момент времени:

Обязательства перед клиентами и партнёрами = Реальные деньги у нас + Внешний поток − Накопленная выручка

Или, простыми словами: всё, что мы должны клиентам, должно быть покрыто реальными деньгами у нас в банке плюс той частью, которую мы уже получили из внешнего мира (equity) минус та часть, которую мы оставили себе как доход (revenue).

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

Инвариант 3. Каждое движение оставляет след

Любая операция — это запись в журнале с временной меткой, инициатором, суммой, типом, источником и получателем. Журнал не редактируется — ошибки исправляются только новыми операциями (например, через ADMIN_TRANSFER).

7. Как читать систему для отчётности

OneWallet устроен так, что любой отчёт строится из той же книги, в которой записаны операции. Никакой отдельной «отчётной БД» не нужно — нет риска, что отчёт «отстал» от реальности или собран с ошибкой.

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

= Сумма по всем кошелькам клиентов + всем кошелькам мерчантов + всем кошелькам агентов.

Это то, что мы должны людям и компаниям на текущий момент. Если у клиента в приложении 1 000 THB — мы обязаны ему эти 1 000 выдать по первому требованию (вывод на банк, перевод другому клиенту, оплата мерчанту).

7.2 Сумма реальной ликвидности

= Сумма по всем Nostro-счетам.

Это сколько реальных денег у нас есть прямо сейчас: в банке-партнёре и на корсчётах у IPPS-шлюза. Эта цифра обязана соответствовать банковской выписке (см. §7.5 про reconciliation).

7.3 Накопленный доход

= Баланс счёта выручки.

Это сколько комиссий мы оставили себе за всё время существования системы. Эта цифра растёт только вперёд (если бухгалтер не делает корректирующих ADMIN_TRANSFER).

7.4 Чистый внешний поток

= Минус баланс equity.

Если equity = −500 000 (отрицательный) — значит, суммарно внешний мир «вложил» в нашу систему 500 000 THB больше, чем забрал. Это объём средств, которые сейчас находятся «у нас» (между клиентскими кошельками и Nostro). Если equity = +200 000 — значит, мы суммарно отдали наружу больше, чем приняли (такое возможно, если, например, выручка системы уже покрывает выводы).

Дельта equity за период = чистый внешний приток денег: насколько изменилась пропорция «вложено − выведено» за квартал, месяц, год.

7.5 Reconciliation: сверка Nostro с реальностью

Каждый день мониторинг сверяет:

  • Cколько по нашей книге должно быть денег у партнёра (баланс соответствующего Nostro).
  • Cколько по выписке партнёра физически у него есть.

Если расхождение больше порога (например, 1 THB) — срабатывает алерт balance drift. Это означает, что либо мы что-то не зачислили вовремя, либо партнёр прислал нам деньги, о которых мы ещё не знаем. В любом случае разбор инцидента — обязателен.

7.6 Готовые отчёты на каждый день

Из этих четырёх чисел собираются все ключевые финансовые отчёты:

  • Daily balance sheet: liability vs. real money vs. equity vs. revenue.
  • Float: сколько денег клиентов «лежит» у нас в обороте.
  • Net inflow / outflow: дельта equity за период.
  • Revenue: дельта счёта выручки за период.
  • Liquidity coverage: отношение Nostro к liability — насколько мы готовы немедленно покрыть все обязательства перед клиентами.

8. Что эта картина даёт каждой роли

8.1 Регулятор / нацбанк

Главный вопрос регулятора — «достаточно ли у вас реальных денег, чтобы покрыть обязательства перед клиентами?». OneWallet отвечает на это двумя цифрами:

  • Сумма средств в обращении = сумма по всем клиентским, мерчантским и агентским кошелькам. Это полные обязательства системы.
  • Сумма ликвидности = сумма по всем Nostro. Это реальные деньги, которыми система может покрыть обязательства.

При корректной работе системы и регулярном reconciliation эти две цифры связаны простым отношением: ликвидность ≥ обязательства минус выручка. Все цифры выводятся напрямую из бухгалтерской книги, никакой ручной сводки не требуется.

Дополнительно для регулятора:

  • Каждая операция, пересекающая границу системы (QP_TOPUP, WITHDRAWAL, IPPS_WITHDRAWAL, THAI_QR_PAY), идентифицируется по типу операции. По любому периоду можно поднять отчёт «сколько вошло и сколько вышло» без отдельной аналитической витрины.
  • Любая клиентская операция оставляет след в журнале, с временной меткой и инициатором — это удовлетворяет требованиям по аудиту.

8.2 Бухгалтер

Бухгалтер читает систему через привычные категории двойной записи:

  • Активы — Nostro-счета: реальные деньги, которыми мы располагаем.
  • Обязательства (пассив) — кошельки клиентов, мерчантов, агентов: то, что мы должны им.
  • Капитал, привнесённый извне — equity: суммарный чистый поток из внешнего мира.
  • Доход — счёт выручки: накопленные комиссии.

Дельта equity за период = чистый внешний приток денег за квартал (новые пополнения минус выводы). Это знакомая бухгалтеру величина — «new money in the system».

Никакой «закрытие месяца» не требуется в смысле «сборки агрегатов»: все цифры — это просто текущие балансы соответствующих счетов в книге. Достаточно зафиксировать снимок на конец отчётного периода.

8.3 Комплайнс-офицер

Комплайнсу нужно отвечать на два класса вопросов:

  1. AML / SAR: «какие операции выглядят подозрительно?». Все операции хранятся в журнале транзакций (tx_history) с типом, суммой, инициатором, временной меткой и контекстом. Можно построить любой фильтр: «все выводы клиента X за последние 30 дней», «все пополнения свыше 100 000 THB по конкретной географии», «частота P2P-переводов в группе пользователей».

  2. KYC и лимиты: «соблюдаются ли установленные пороги?». Каждая операция перед исполнением проверяется на соответствие лимитам клиента (уровню KYC, дневному / месячному потолку, NFC-лимитам). Журнал содержит как успешные, так и отклонённые попытки — есть полная картина «что система разрешила, что — нет, и почему».

Кроме того:

  • Внешний поток (TOPUP / WITHDRAWAL / QR / PromptPay) явно отделён от внутреннего (P2P / MINIAPP / INVOICE / NFC / SERVICE / ADMIN). Комплайнс может строить отчёты «деньги пересекли границу системы» отдельно от «деньги двигались внутри».
  • Каждая операция несёт trace_id — единый сквозной идентификатор, по которому в случае запроса можно поднять полный контекст (инициатор, шаги выполнения, статус каждого шага, время).

8.4 Продакт и аналитика

Продактам и аналитикам та же книга даёт сырьё для метрик:

  • GMV (gross merchandise value) — сумма мерчантских платежей (INVOICE_PAYMENT + NFC_CHARGE + MINIAPP_CHARGE).
  • P2P-активность — объём P2P_TRANSFER.
  • Внешний оборот — объём пересечений границы системы.
  • Take rate — дельта revenue к общему объёму операций за период.
  • Float — средний остаток на клиентских кошельках за период.

Никакого отдельного ETL не требуется: метрики читаются непосредственно из бухгалтерской книги и журнала транзакций.

9. Краткие ответы на частые вопросы

Почему equity может быть отрицательным — это не «отрицательный капитал»? Нет. В нашей конструкции equity — это бухгалтерская техника, которая трекает суммарный поток через границу системы. Отрицательное значение означает «к нам пришло больше денег, чем мы отдали наружу» — и это абсолютно нормально для растущего кошелька с миллионами пополнений. Это не сигнал убытка.

Почему transit всегда нулевой, а другие счета — нет? Потому что транзит по своей природе — «коридор». Деньги через него проходят. В отличие от кошелька, на котором деньги «лежат», и от revenue, который «копит». Эта разница встроена в саму конструкцию системы и обеспечена правилом двойной записи: каждая операция, проходящая через транзит, имеет одинаковую сумму на входе и выходе.

Если деньги клиента «у нас в банке», почему мы не можем ими распоряжаться? Не можем — потому что это не наши деньги. Цифра на клиентском кошельке — это обязательство OneWallet перед клиентом. Реальные деньги в банке-партнёре — наша ликвидность, обеспечивающая эти обязательства. Если соотношение нарушено (Nostro < liability), это инцидент, а в худшем случае — нарушение лицензионных требований.

Что бывает, если на Nostro накопилось больше денег, чем должно быть? Это тоже инцидент, но менее опасный. Скорее всего, партнёр прислал нам деньги по операции, которую мы ещё не успели разнести по кошелькам (например, задержка вебхука). Reconciliation срабатывает, оператор разбирает, при необходимости делает корректировку через ADMIN_TRANSFER.

Может ли система «создать» деньги из воздуха? Нет. Двойная запись делает это математически невозможным: каждая запись «прихода» обязана сопровождаться записью «ухода» на ту же сумму. Единственный способ «увеличить общую сумму денег в системе» — получить их извне через QP_TOPUP (и тогда equity уйдёт в минус на эту же сумму, скомпенсировав).

Зачем нужны отдельные транзитные счета на каждый канал? Это упрощает анализ. Если транзит ушёл в ненулевой остаток — мы сразу знаем, на каком канале сломалось: внутренний перевод, IPPS, мерчантский инвойс, мини-апп или админ-канал. Если бы транзит был один — мы видели бы только сам факт инцидента, без локализации.

10. Где это в коде

Этот документ — высокоуровневое описание. Технические детали и конкретные имена классов / структуры таблиц живут в dev-разделе:

  • ../dev/architecture/05-tigerbeetle-accounts.md — устройство счетов внутренней бухгалтерии: какие классы существуют, как именуются, какие правила к ним применяются и как обеспечивается инвариант transit = 0.
  • ../dev/integrations/tigerbeetle.md — описание ledger как технического компонента: модель транзакций, гарантии атомарности, детерминированные идентификаторы.
  • ../dev/integrations/ipps.md — как устроена интеграция со шлюзом PromptPay / IPPS, через который физически проходят входящие и исходящие платежи.
  • ../dev/operations/runbook.md — операционные процедуры, включая обработку алерта balance_drift при расхождении Nostro с реальной банковской выпиской.

См. также соседние бизнес-документы: