Вопросы бухгалтеру — план счетов и логика балансов¶
Для кого: Главный бухгалтер / финансовый контролёр компании
Цель встречи: Получить исходные данные для настройки финансового ядра системы (blnkfinance)
Контекст: Мы строим платёжную платформу OneWallet. Все движения денег записываются через двойную бухгалтерскую запись в blnkfinance. Без правильной структуры счетов невозможно корректно считать балансы, комиссии, делать сверку с банками и отчитываться перед регулятором.
Блок 1 — Общая структура плана счетов¶
Зачем блок: blnkfinance организован в иерархию Ledger (группа) → Balance (счёт). Прежде чем создавать что-либо в системе, нужно понять какие укрупнённые группы счетов нам нужны и где граница между "нашими деньгами" и "деньгами клиентов".
1. Какие счета верхнего уровня нам нужны?
Что имеется в виду: В классической бухгалтерии всё делится на 5 групп: Активы, Пассивы/Обязательства, Капитал, Доходы, Расходы. В blnkfinance мы создаём Ledger-ы (контейнеры), и важно понять — сколько таких групп нам нужно и как они называются у нас.
Пример: У нас уже задуманы 4 Ledger-а: user_wallets, platform_operations, fees_and_commissions, suspense. Бухгалтер должен подтвердить, что этого достаточно, или добавить, например, agent_floats, partner_prepaid.
Зачем мне: Если потом окажется, что нужен ещё один уровень — переписывать всю структуру дорого.
2. Деньги клиентов — это наши обязательства перед ними. На каком счёте они должны отражаться?
Что имеется в виду: Клиент положил 1000 БАТ на кошелёк. Это не наши деньги — мы их должны вернуть по требованию. В балансе компании это обязательство (liability). Нужно понять: как именно это должно быть видно в финансовой отчётности.
Пример: Вариант А — клиентские средства отражаются как "Кредиторская задолженность перед клиентами". Вариант Б — хранятся на отдельном номинальном банковском счёте и не смешиваются с операционными деньгами компании.
Зачем мне: Это влияет на то, как строить Ledger user_wallets — нужен ли там зеркальный счёт-обязательство, или достаточно одного balance на клиента.
3. Используем ли мы segregated account (номинальный/обособленный счёт) для клиентских средств?
Что имеется в виду: Регуляторы часто требуют, чтобы деньги клиентов лежали на отдельном банковском счёте и не смешивались с операционными деньгами компании (зарплаты, аренда и т.д.). Это называется "номинальный счёт" или "клиентский пул".
Пример: Клиент А положил 500 БАТ, клиент Б — 300 БАТ. В банке на специальном счёте лежит 800 БАТ. В нашей системе — два отдельных balance: user_A_bat и user_B_bat. Сумма их балансов всегда должна равняться 800 БАТ в банке.
Зачем мне: Если segregated account обязателен — нужно настроить автоматическую сверку между суммой всех клиентских balance в blnkfinance и остатком на банковском счёте. Это отдельный reconciliation pipeline.
4. Как отражается разрыв между "деньги в системе" и "деньги фактически в банке"?
Что имеется в виду: Всегда есть транзакции в пути — например, клиент пополнил кошелёк, наша система уже показывает +1000, но деньги от платёжного шлюза ещё не пришли на банковский счёт (T+1 или T+2 delay). Этот разрыв нужно где-то отражать.
Пример: Клиент пополняет через карту Visa. Банк-эквайер переведёт деньги нам только завтра. Что отражаем сегодня? Дебет "Дебиторка по расчётам с эквайером" / Кредит "Обязательства перед клиентом".
Зачем мне: В blnkfinance для этого используется статус INFLIGHT — транзакция зарезервирована, но не применена. Нужно понять, на каком именно счёте должна "висеть" эта сумма до подтверждения.
5. Нужны ли счета в нескольких валютах? Как ведётся переоценка?
Что имеется в виду: Если мы работаем в THB и USD одновременно, то каждый balance существует в конкретной валюте. При отчётности нужно привести всё к одной валюте — это называется переоценка (revaluation). Курсовая разница при этом — это доход или расход.
Пример: У клиента balance user_123_usd = 100 USD. Курс вчера был 87, сегодня 88. Рублёвый эквивалент вырос. Как это отражать в отчётности — автоматически ежедневно или только при закрытии периода?
Зачем мне: blnkfinance поддерживает мультивалютность, но логику переоценки нужно реализовывать самостоятельно. Если этого не требуется — упрощаем архитектуру.
Блок 2 — Клиентские балансы¶
Зачем блок: В blnkfinance каждый
balance— это отдельный счёт. Нужно решить: один balance на клиента или несколько (основной + замороженные + бонусные). Это фундаментальное архитектурное решение, которое потом сложно изменить.
6. Каждый клиент — отдельный субсчёт, или балансы клиентов агрегируются?
Что имеется в виду: Вариант А — у каждого клиента свой именованный счёт user_123_THB. Вариант Б — все клиентские деньги лежат в одном общем пуле, а индивидуальный баланс считается математически через историю транзакций.
Пример: В большинстве платёжных систем — Вариант А. Но бухгалтеру важно знать: как это выглядит в управленческой отчётности? "10 000 клиентов — 10 000 счетов" или "1 счёт с аналитикой по клиентам".
Зачем мне: blnkfinance поддерживает оба подхода. Выбор влияет на производительность и на то, как строить отчёты.
7. Как выглядит проводка при пополнении баланса клиентом через внешний шлюз?
Что имеется в виду: Клиент нажал "Пополнить через Visa". Деньги прошли через платёжный шлюз и должны отразиться на балансе. Нужно понять какие именно два счёта участвуют в проводке.
Пример (текущая логика в системе):
Но возможно бухгалтер скажет, что правильнее:Дебет: bank_account_THB (деньги фактически в банке)
Кредит: client_liabilities (обязательства перед клиентами)
Зачем мне: Текущая схема в docs/07-blnkfinance.md — упрощённая. Нужно верифицировать её у бухгалтера.
8. Как выглядит проводка при переводе между двумя клиентами внутри системы (P2P)?
Что имеется в виду: Клиент А отправил клиенту Б 500 THB. Деньги не уходят из системы, просто перераспределяются между двумя внутренними балансами.
Пример:
Вопрос: нужна ли комиссия на P2P? Если да — появляется третья строка в проводке.Зачем мне: P2P — простейший случай, но важно подтвердить что никаких промежуточных транзитных счетов не требуется. Иначе усложняем логику.
9. Как выглядит проводка при выводе средств (withdraw)?
Что имеется в виду: Клиент выводит деньги на карту или банковский счёт. Деньги уходят из нашей системы наружу.
Пример:
Дебет: user_123_THB -1000 (баланс клиента уменьшился)
Дебет: user_123_THB -50 (комиссия за вывод)
Кредит: outgoing_pool_THB +1000 (деньги идут наружу через шлюз)
Кредит: platform_commission_THB +50
Зачем мне: Нужно понять, списывается ли комиссия "поверх" суммы или "внутри" суммы. Это влияет на UX и на то, как считать комиссию в blnkfinance.
10. Как учитывается заморозка средств (hold/reserve)? Это отдельный счёт или статус транзакции?
Что имеется в виду: Иногда нужно заморозить часть средств клиента — например, при спорной транзакции или при резервировании для оплаты. Деньги технически есть, но клиент не может ими воспользоваться.
Пример:
Вариант А — отдельный balance user_123_THB_hold куда деньги "перемещаются" на время заморозки.
Вариант Б — используется механизм INFLIGHT в blnkfinance, который блокирует сумму без перемещения.
Зачем мне: Это влияет на то, какой баланс показывать клиенту в приложении — balance.balance или balance.balance - balance.inflight_balance.
11. Кэшбэк и бонусные баллы — это деньги или отдельная валюта?
Что имеется в виду: Если мы начисляем кэшбэк — это реальные THB, которые клиент может потратить, или условные "баллы" которые конвертируются по своим правилам?
Пример:
Реальный кэшбэк → отдельный balance user_123_THB_cashback (настоящие деньги, ограниченные по использованию).
Баллы → отдельная "валюта" POINTS в blnkfinance, не являющаяся деньгами.
Зачем мне: Если кэшбэк — настоящие деньги, нужен отдельный liability-счёт "Обязательства по программе лояльности". Это влияет на финансовую отчётность.
12. Как правильно проводить возврат (refund)? Обратная проводка или отдельная транзакция?
Что имеется в виду: Клиент заплатил за услугу, услугу отменили, нужно вернуть деньги. В бухгалтерии есть два подхода: сторнирование (как будто транзакции не было) или новая обратная проводка.
Пример:
blnkfinance имеет встроенный механизм Refund-транзакций — они создают новую запись со ссылкой на оригинал. Но нужно подтвердить, что это бухгалтерски корректно, и вся комиссия тоже возвращается.
Зачем мне: Неправильный учёт refund-ов — частая причина расхождений при аудите.
Блок 3 — Сервисные счета (комиссии)¶
Зачем блок: Комиссии — основной доход платформы. Важно понять: в какой момент они признаются доходом, как делятся между платформой и партнёрами, и нужны ли промежуточные счета.
13. В какой момент комиссия признаётся доходом — в момент списания или после успешного завершения транзакции?
Что имеется в виду: Есть два подхода. Агрессивный: списали комиссию — сразу доход. Консервативный: комиссия висит в "отложенном доходе" пока транзакция не завершилась успешно.
Пример:
Клиент инициировал платёж 1000 + комиссия 20. Мы списали 1020 с баланса. Но платёж провайдер может ещё отклонить. Если мы уже признали 20 как доход, а потом делаем refund — появляется сторно дохода.
Зачем мне: Это влияет на то, нужен ли нам счёт deferred_commission или достаточно сразу писать в platform_commission.
14. Куда попадает комиссия и нужна ли детализация по типу операции?
Что имеется в виду: Все комиссии можно складывать в один счёт platform_commission, а можно разделять: commission_topup, commission_p2p, commission_withdrawal, commission_payment.
Пример:
Если финансовый директор хочет видеть "сколько мы заработали на переводах" отдельно от "сколько на пополнениях" — нужна детализация. Если достаточно общей суммы — один счёт.
Зачем мне: В blnkfinance детализацию можно делать либо отдельными balance-ами, либо через metadata на транзакции. Первый подход проще для отчётности, второй — меньше счетов.
15. Если комиссия делится между нами и агентом — как это отражается?
Что имеется в виду: Агент привлёк клиента, клиент заплатил комиссию 20 THB. Из них 15 — нам, 5 — агенту. Вопрос: в момент транзакции делаем сплит сразу, или сначала всё идёт нам, а потом мы переводим агенту?
Пример:
Вариант А (split at source):
Дебет: user_THB -20
Кредит: platform_commission_THB +20
// ... потом при расчёте с агентом:
Дебет: platform_commission_THB -5
Кредит: agent_revenue_A_THB +5
Зачем мне: blnkfinance поддерживает multi-destination транзакции (Вариант А). Но если бухгалтер предпочитает Вариант Б — реализация другая.
16. Нужен ли транзитный счёт для комиссий до их распределения?
Что имеется в виду: Иногда удобно сначала собрать все комиссии в один "котёл" (fee_pool), а в конце дня/недели распределить их по нужным счетам. Это упрощает аудит, но добавляет шаг.
Пример:
В конце дня запускается Job, который берёт все накопленные комиссии из fee_pool и распределяет: 70% → platform_income, 20% → agent_payable, 10% → reserve.
Зачем мне: Если это нужно — добавляем scheduled job в архитектуру. Если нет — обходимся без него.
17. Комиссия провайдера (банка, эквайера) — это наш расход или уменьшение дохода?
Что имеется в виду: Платёжный шлюз берёт с нас, например, 1.5% за каждую транзакцию. Это можно отражать двумя способами: как прямой расход компании, или как уменьшение валового дохода от комиссий (net revenue).
Пример:
Клиент заплатил нам комиссию 20 THB. Мы заплатили шлюзу 10 THB.
Вариант А: Доход = 20, Расход на шлюз = 10, Прибыль = 10.
Вариант Б: Чистый доход = 10 (сразу считаем нетто).
Зачем мне: Это влияет на то, нужен ли нам отдельный счёт provider_fees (расход) или достаточно записывать нетто в platform_commission.
Блок 4 — Агентские счета¶
Зачем блок: Агенты — отдельная категория участников. Они держат собственный float (предоплаченные средства), получают вознаграждение и рассчитываются с нами периодически. Это требует специальной логики счетов.
18. Float агента — это депозит (наше обязательство перед ним) или предоплата за услуги?
Что имеется в виду: Агент вносит 50 000 THB, чтобы иметь возможность проводить операции. Как это классифицировать? Если это депозит — мы обязаны вернуть по требованию. Если предоплата — это наш доход, который "сгорает" по мере операций.
Пример:
В большинстве систем float агента = обязательство. Агент "загружает" float, проводит операции, его float уменьшается. Если хочет — выводит остаток.
Зачем мне: Определяет, в каком Ledger держать агентские балансы — в user_wallets (как у обычных клиентов) или в отдельном agent_floats с другой логикой.
19. Как учитывается выдача наличных агентом клиенту (cash-out)?
Что имеется в виду: Клиент приходит к агенту, хочет снять наличные. Агент выдаёт из кассы, а в системе происходит списание с баланса клиента и уменьшение float агента.
Пример:
Дебет: user_123_THB -1000 (клиент отдал электронные деньги)
Кредит: agent_float_A_THB +1000 (агент принял электронные деньги)
// В реальности агент отдал наличные — это вне системы
// Агент потом пополнит свой float через банк
Зачем мне: Нужно понять как float агента "восстанавливается" — это отдельная транзакция пополнения или автоматический взаимозачёт.
20. Вознаграждение агента — начисляется в момент каждой операции или накапливается?
Что имеется в виду: Агент заработал 5 THB на операции. Когда это фиксируется? Сразу в момент операции на отдельном счёте agent_earned_A? Или в конце месяца при расчёте?
Пример:
Если начисляем сразу — у агента растёт agent_earned, он видит это в реальном времени.
Если накапливаем и пересчитываем в конце периода — проще бухгалтерски, но агент не видит текущее вознаграждение.
Зачем мне: Это влияет на UX агентского приложения (показываем ли заработок в реальном времени) и на сложность схемы счетов.
21. Как происходит расчёт (settlement) с агентом — вручную или автоматически?
Что имеется в виду: Раз в неделю/месяц нужно перевести агенту накопленное вознаграждение. Как это происходит: оператор вручную нажимает "выплатить", или система делает это автоматически по расписанию?
Пример:
При расчёте:
Дебет: agent_earned_A_THB -5000 (начисленное вознаграждение списывается)
Кредит: outgoing_pool_THB +5000 (деньги идут агенту через банковский перевод)
Зачем мне: Автоматический settlement требует scheduled job и дополнительной логики. Нужно знать требования заранее.
22. Если float агента уходит в минус — это технически допустимо?
Что имеется в виду: Может ли агент провести операцию, если его float недостаточен? Если да — возникает "технический" овердрафт. Как это учитывается — как наш риск (дебиторка) или блокируется на уровне системы?
Пример:
Агент имеет float 1000, хочет провести операцию на 1500. Система должна: а) запретить, б) разрешить и выставить задолженность.
Зачем мне: В blnkfinance есть флаг allow_overdraft на уровне транзакции. Нужно знать политику, чтобы правильно его настроить.
Блок 5 — Интеграционные счета (партнёры, B2B)¶
Зачем блок: Если платформу используют B2B-партнёры через API (например, другой сервис интегрируется с нами для проведения платежей), нужно отдельно отслеживать их балансы и задолженности.
23. У каждого B2B-партнёра свой счёт, или они работают через единый пул?
Что имеется в виду: Партнёр А и Партнёр Б оба используют наш API. Деньги, которые они перемещают через нас — это отдельные счета или всё идёт через общие incoming_pool/outgoing_pool?
Пример:
Если нужна детализация по партнёру (для их отчётности или для сверки) — отдельный balance partner_A_prepaid. Если партнёр работает просто как ещё один канал — можно без отдельного счёта, только метаданные на транзакции.
Зачем мне: Отдельные счета = больше Ledger-ов в blnkfinance, но чище отчётность. Метаданные = меньше счетов, но сложнее запросы.
24. Партнёр работает на предоплате или на постоплате?
Что имеется в виду: Prepaid — партнёр сначала вносит депозит, потом тратит. Postpaid — партнёр работает в кредит, платит в конце месяца.
Пример:
Prepaid: partner_A_prepaid_THB = 100 000 → транзакции уменьшают этот balance.
Postpaid: счёт может уходить в минус, в конце периода выставляется invoice, партнёр платит.
Зачем мне: Postpaid требует отдельного счёта дебиторской задолженности и логики выставления счетов (invoicing), что не предусмотрено в blnkfinance из коробки.
Блок 6 — Внешние платёжные шлюзы¶
Зачем блок: Каждый внешний шлюз (банк, эквайер, SWIFT, PromptPay, QP API и т.д.) — это отдельный канал движения реальных денег. В нашей системе каждому шлюзу должен соответствовать счёт, который отражает, сколько денег "находится" у этого шлюза.
25. Для каждого шлюза — отдельный счёт в системе?
Что имеется в виду: У нас есть несколько каналов: IPPS PPXC (тайская система), QP API, возможно прямое банковское соединение. Каждому должен соответствовать баланс в нашей системе, отражающий "сколько денег сейчас у этого шлюза по нашим данным".
Пример:
gateway_ipps_ppxc_thb — деньги, отправленные через PPXC
gateway_qp_api_usd — деньги, отправленные через QP API
bank_main_THB — деньги на основном банковском счёте
Зачем мне: Без этих счетов невозможно сделать сверку: "мы думаем, что у шлюза X находится Y денег" vs "шлюз говорит, что у него Z".
26. Как учитывается транзакция в состоянии "отправлено, но не подтверждено шлюзом"?
Что имеется в виду: Клиент инициировал платёж. Мы отправили запрос в шлюз. Ждём ответа. В этот момент баланс клиента уже уменьшился, но деньги ещё не дошли до получателя. Где "висят" деньги в этот момент?
Пример:
blnkfinance решает это через статус INFLIGHT. Транзакция создана, деньги заблокированы на балансе клиента, но не переведены. После подтверждения от шлюза — переводятся в APPLIED.
Вопрос бухгалтеру: нужен ли нам отдельный счёт transit_ipps_thb для этих сумм, или достаточно использовать inflight_balance в blnkfinance?
Зачем мне: Это влияет на то, как мы считаем "реальный" баланс системы в любой момент времени.
27. Как отражается успешная транзакция через внешний шлюз — полная проводка?
Что имеется в виду: Нужно описать все счета, которые участвуют в успешном исходящем платеже через шлюз — от начала до конца.
Пример (текущая логика):
1. Создаём INFLIGHT:
Дебет: user_123_THB (баланс клиента уменьшился)
Кредит: outgoing_pool_THB (деньги зарезервированы для вывода)
2. Шлюз подтвердил → переводим в APPLIED:
Дебет: outgoing_pool_THB (pool уменьшился)
Кредит: gateway_ipps_THB (деньги "ушли" к шлюзу по нашим данным)
Зачем мне: Нужно верифицировать эту цепочку у бухгалтера. Возможно, цепочка должна быть другой или нужны дополнительные шаги.
28. Как обрабатывается неуспешная транзакция (failed/declined)?
Что имеется в виду: Шлюз отклонил платёж. Клиент должен получить деньги обратно. Как именно это отражается — немедленный возврат или процесс занимает время?
Пример:
При rejection в blnkfinance транзакция меняет статус на REJECTED, inflight-блокировка снимается автоматически. Но нужно понять: нужно ли создавать отдельную "возвратную" транзакцию в records, или статус REJECTED уже достаточен для аудита?
Зачем мне: Влияет на audit trail и на то, что видит клиент в истории операций.
29. Как учитывается chargeback (принудительный возврат по инициативе банка клиента)?
Что имеется в виду: Клиент пожаловался в свой банк, банк инициировал chargeback. Шлюз снимает деньги с нашего счёта. Кто несёт потери — мы (компания) или клиент, которому уже была оказана услуга?
Пример:
Если несём мы:
Дебет: chargeback_losses_THB +сумма (наш убыток)
Кредит: gateway_account_THB -сумма (шлюз списал с нас)
Зачем мне: Нужна политика и соответствующий счёт в плане счетов. Без этого chargeback-и будут отражаться некорректно.
30. Settlement period шлюза (T+1, T+2) — где деньги "висят" в это время?
Что имеется в виду: Многие шлюзы переводят деньги не мгновенно, а через 1-2 рабочих дня. Например, сегодня клиент пополнил кошелёк через карту, а деньги на наш банковский счёт придут завтра.
Пример:
Сегодня:
Дебет: receivable_from_gateway +1000 (шлюз нам должен)
Кредит: user_123_THB +1000 (клиент уже видит деньги)
Завтра (при получении от шлюза):
Дебет: bank_account_THB +1000
Кредит: receivable_from_gateway -1000
Зачем мне: Без этого счёта "дебиторка от шлюза" не видна, и баланс системы не сходится с банковской выпиской.
Блок 7 — Сверка (Reconciliation)¶
Зачем блок: Сверка — ежедневный процесс проверки того, что внутренние данные системы совпадают с данными банков и шлюзов. Без правильной схемы счетов сверка невозможна или даёт неправильные результаты.
31. Как часто происходит сверка и кто её инициирует?
Что имеется в виду: Сверка может быть ежедневной автоматической, еженедельной ручной, или после каждого batch-расчёта со шлюзом.
Пример:
Каждый день в 23:59 система автоматически запрашивает выписку у шлюза за прошедший день и сравнивает с внутренними данными blnkfinance. Расхождения попадают в suspense Ledger.
Зачем мне: blnkfinance имеет встроенный reconciliation engine. Нужно знать частоту и формат данных от шлюзов, чтобы правильно настроить pipeline.
32. Что делать с расхождениями при сверке — где они "висят" до выяснения?
Что имеется в виду: Шлюз говорит "у нас 100 транзакций", мы видим 99. Одна транзакция пропала или задвоилась. Пока не выяснили причину — сумму нужно где-то зафиксировать.
Пример:
В blnkfinance у нас есть suspense Ledger с баланTHB reconciliation_diff_THB. Туда попадают "неопознанные" суммы. Пока специалист не разберётся и не перенесёт в правильный счёт.
Вопрос бухгалтеру: каков допустимый срок нахождения суммы в suspense? Есть ли регуляторные ограничения?
Зачем мне: Нужно настроить алерты — если в suspense "завис" остаток дольше N дней, это сигнал тревоги.
33. Нужен ли счёт "pending settlement" отдельно от "settled"?
Что имеется в виду: Транзакция прошла успешно, но деньги ещё не перечислены от шлюза на наш счёт (T+1). Нужен ли отдельный счёт pending_settlement или достаточно отметить статус в metadata?
Пример:
pending_settlement_ipps_THB — деньги, которые шлюз нам обещал, но ещё не прислал
settled_from_ipps_THB — деньги, которые фактически получены
Зачем мне: Это прямо влияет на cash flow — сколько денег у нас "на бумаге" vs "реально в банке".
34. Как ведётся учёт курсовой разницы при мультивалютных расчётах?
Что имеется в виду: Если шлюз рассчитывается в THB, а мы ведём учёт в THB, при конвертации возникает разница из-за изменения курса между моментом транзакции и моментом фактического расчёта.
Пример:
Транзакция 100 THB × курс 3.4 = 340 THB — зафиксировали.
Шлюз перевёл через 2 дня, курс стал 3.41. Получили 341 THB.
Разница 1 THB = курсовая прибыль → куда списать?
Зачем мне: Нужен счёт fx_gain_loss и чёткий момент, когда фиксируется курс для целей учёта.
Блок 8 — Регуляторика и отчётность¶
Зачем блок: НацБанк и налоговые органы требуют отчётность в определённых форматах. Если структура счетов изначально не соответствует требованиям — придётся строить сложные трансформации данных. Лучше сделать правильно сразу.
35. Какие отчёты нужны регулятору и в каком разрезе?
Что имеется в виду: НацБанк (или аналогичный регулятор) обычно требует: реестр клиентских счетов, общий объём операций за период, остатки клиентских средств, подозрительные транзакции (AML).
Пример:
Если регулятор хочет "объём P2P переводов по дням" — нужно, чтобы P2P транзакции имели отдельный тип/тег в blnkfinance. Если сейчас этого нет — потом придётся перебирать всю историю.
Зачем мне: Теги/типы транзакций нужно проставлять с первого дня. Ретроактивно это невозможно (immutable ledger).
36. Нужен ли аудиторский trail — возможность восстановить любой баланс на любую дату в прошлом?
Что имеется в виду: "Какой был баланс клиента 123 на 1 января?" — система должна уметь ответить на этот вопрос точно. blnkfinance поддерживает Balance Snapshots для этого.
Пример:
Аудитор приходит и говорит: "Покажите балансы всех клиентов на 31 декабря прошлого года". Если снимки не делались — придётся восстанавливать из истории транзакций (медленно и рискованно).
Зачем мне: Нужно настроить periodic snapshots в blnkfinance с первого дня работы системы.
37. Как учитывается обязательный резерв (если требуется регулятором)?
Что имеется в виду: Некоторые регуляторы требуют держать N% от клиентских средств в качестве резерва. Эти деньги нельзя использовать операционно.
Пример:
Если суммарный клиентский float = 10 000 000 THB, а требование резерва 5% — то 500 000 THB должны лежать на специальном счёте и не трогаться.
Зачем мне: Нужен отдельный счёт regulatory_reserve_THB и автоматический расчёт его целевого значения. Если это требование есть — добавляем в архитектуру.
38. Нужно ли вести учёт в разрезе нескольких юридических лиц?
Что имеется в виду: Если операционная деятельность ведётся через несколько компаний (например, одна держит лицензию, другая занимается технической частью), балансы могут нужно разделять между ними.
Пример:
"ООО ОнеВоллет" держит клиентские деньги.
"ООО ОнеВоллет Тех" оказывает IT-услуги и получает вознаграждение.
Их балансы не должны смешиваться — нужны отдельные Ledger-ы или отдельные инстансы blnkfinance.
Зачем мне: Это может потребовать существенного усложнения архитектуры. Лучше узнать заранее.
39. Как хранить историю изменений тарифов для корректного пересчёта комиссий?
Что имеется в виду: Сегодня комиссия за P2P = 1%, с 1 мая станет 1.5%. Если клиент оспаривает транзакцию за прошлый месяц — нужно знать, какой тариф действовал тогда.
Пример:
Это не задача blnkfinance (он хранит факт транзакции). Это задача основной базы данных. Но на каждой транзакции в blnkfinance можно хранить metadata с примененным тарифом.
Зачем мне: Нужно решить — хранить тариф в metadata транзакции или только в отдельной таблице истории тарифов. Первый вариант проще для аудита.
40. Каков порядок закрытия периода (month-end closing) и нужна ли автоматизация?
Что имеется в виду: В бухгалтерии в конце месяца происходит ряд операций: начисление резервов, переоценка валют, сверка с банками, формирование отчётов. Часть из этого можно автоматизировать.
Пример:
В последний день месяца система автоматически: создаёт snapshot всех балансов, запускает reconciliation по всем шлюзам, формирует отчёт по комиссиям, рассчитывает вознаграждение агентов.
Зачем мне: Если автоматизация нужна — это отдельные scheduled jobs в архитектуре. Объём работы зависит от ответа.
Итоговая цель встречи¶
По результатам встречи нам нужно получить:
- Подтверждённую структуру Ledger-ов в blnkfinance (название, назначение, список Balance-ов внутри каждого)
- Матрицу проводок для каждого типа операции (top-up, P2P, withdrawal, refund, commission split, agent settlement)
- Список счетов которые нужны дополнительно к уже задуманным
- Политику по спорным/подвешенным суммам (suspense)
- Требования регулятора которые влияют на структуру данных