Платформа 4pay.online выпускает банковский контур и переводит ядро на событийную модель хранения. Два изменения вышли вместе не случайно: второе — фундамент, на котором держится первое.
Компания, которая хочет дать клиенту не только платёж, но и счёт, обычно приходит к конструкции из двух систем. Отдельно покупается банковская система учёта, отдельно подключается платёжный шлюз, между ними пишется интеграция.
Дальше начинается то, что съедает бюджет запуска. Два поставщика с разными сроками реакции. Два договора с разной ответственностью. Две линии поддержки, каждая из которых при расхождении данных уверена, что проблема на другой стороне. Отдельная команда, которая сводит остатки в двух системах и раз в месяц объясняет разницу. И полгода до первого клиента, потому что интеграция между учётом и платежами — это не подключение по документации, а согласование двух моделей данных, которые проектировались независимо друг от друга.
Мы построили банковский контур как часть платформы именно поэтому. Счета, вклады, кредиты и приём платежей живут в одном контуре, с общей консолью, общим учётом и общей сверкой.
В контур вошли счета с планом счетов, депозиты с начислением процентов, кредитные продукты с графиками платежей, казначейство и главная книга. Отдельно сделаны выпуск карт, интерфейсы регуляторной отчётности, постоянные поручения, переводы и торговое финансирование.
За этим перечнем стоит одна разница, которую стоит проговорить прямо: платёжный сервис и банковский продукт отличаются не набором функций, а отношением ко времени.
Платёж — событие. Он проходит, фиксируется и забывается; всё, что нужно о нём знать, известно в момент завершения. Счёт — процесс. Он живёт годами: на остаток начисляются проценты, часть средств блокируется под операции, по кредиту идёт график погашения, каждое движение отражается в плане счетов по своим правилам, а в конце периода всё это должно сойтись в отчётности. Дописать процесс надстройкой к системе, спроектированной под события, не удаётся — точнее, удаётся ровно до первой проверки.
Требование, которое рано или поздно получает каждая финансовая компания, звучит так: покажите состояние этого счёта на такое-то число прошлого года. Его задают аудитор, банк-партнёр, регулятор и клиент в споре.
Обычная система хранит только текущие значения — остаток счёта, статус операции — и перезаписывает прежние при каждом изменении. История ведётся отдельным журналом, который со временем расходится с данными: где-то запись не создалась, где-то создалась дважды, где-то правка прошла мимо журнала. Ответить на такой запрос без ручной реконструкции невозможно, а результат реконструкции нельзя защитить перед проверяющим.
Теперь платформа хранит последовательность событий: счёт открыт, средства зачислены, комиссия удержана, операция отменена. Остаток вычисляется из этой истории, ничего не перезаписывается, а исправление ошибки становится ещё одним событием, а не молчаливой правкой. Отчёт на любую дату собирается системой, а спорная операция разбирается по зафиксированным фактам.
Это третье поколение ядра: первое мы начали разрабатывать в 2018 году, второе, с единой моделью операции и подключаемыми провайдерами, — в январе 2022-го.
Отсюда же следуют свойства, которые в обычной схеме приходится выстраивать вручную и потом годами ловить их отказы.
Повторная доставка события не создаёт вторую проводку — а значит, сбой связи с провайдером не приводит к двойному зачислению, которое потом ищут вручную по выпискам.
Блокировка средств проходит одним неделимым действием. Между проверкой остатка и постановкой блокировки не может вклиниться другая операция, поэтому классический сценарий с двумя одновременными списаниями последних денег со счёта здесь не воспроизводится.
Прерванная сбоем операция либо доводится до конца, либо откатывается целиком: незавершённых состояний, требующих ручного разбора наутро, не остаётся.
Ручная корректировка баланса выполняется пакетом, подтверждается одноразовым кодом и остаётся в истории навсегда. Для внутреннего контроля это означает, что любое вмешательство человека в остатки видно и объяснимо.
Компаниям, запускающим цифровой банк или карточную программу, контур даёт готовую учётную основу: не нужно выбирать между покупкой тяжёлой банковской системы и написанием собственной. Лицензия, отношения с регулятором и договоры с банками-партнёрами при этом остаются на стороне клиента — мы техническая платформа, а не финансовая организация, и берём на себя учётную и операционную часть, а не правовую.
Финтех-командам, которым нужен счёт клиента, а не только транзакция, — возможность строить продукт вокруг остатка: накопительные сценарии, рассрочки, кошельки с процентом.
Отраслевым платформам с кошельками участников — маркетплейсам, сервисам заказа услуг, логистическим площадкам — учёт средств участников по правилам, которые выдержат проверку, а не таблицу внутренних балансов, написанную на коленке.
Всем трём категориям это даёт ещё один аргумент в разговоре с аудитором, банком-партнёром и регулятором: любую цифру в отчёте можно разложить на факты и показать, откуда она взялась.
Ближайшие планы связаны с продуктами, которые становятся возможны только поверх учётной основы: направлением коллективного и долевого финансирования и расчётными контурами для сообществ. О них мы расскажем отдельно в ближайшие месяцы.
«Разница между платёжным сервисом и банковским продуктом — в учёте. Платёж закончился и забылся, а счёт живёт годами: проценты, блокировки, графики погашения, отражение каждой операции в плане счетов. И рано или поздно у вас спросят, почему в отчёте одна цифра, а в выписке другая», — Михаил Спиридонов, директор «Два ПиЭр».
Продукт: 4pay.online/use-cases/neobank