Что такое виртуальный IBAN?

Виртуальный IBAN (vIBAN) — это настоящий, доступный для платежей международный номер банковского счёта, выпущенный из выделенного диапазона и привязанный к одному основному счёту. Он принимает платежи как любой другой IBAN: плательщик отправляет на него обычный кредитовый перевод SEPA из своего банка. Но собственного баланса у него нет. Его задача — идентификация: каждый виртуальный IBAN закреплён ровно за одним плательщиком или назначением, поэтому платёж, пришедший на него, уже говорит, кто его отправил и за что. Деньги автоматически собираются на основном счёте; виртуальный IBAN — это метка платежа, а не второе место, где лежат деньги.

Это единственное свойство — один IBAN на плательщика — и есть вся идея. Чтобы понять, зачем о нём писать отдельную статью, начнём с проблемы, которую оно устраняет.

Настоящая проблема: сопоставить деньги с плательщиками

Представьте бизнес, который принимает оплату банковскими переводами на один счёт: аренда, подписки, счета. Все поступления приходят на один и тот же IBAN, а единственная подсказка, кто заплатил, — то, что плательщик вписал в поле назначения платежа. В назначении делают опечатки, его обрезают где-то по цепочке или вовсе оставляют пустым. Перевод на €49.00 с искажённым назначением — это ещё не €49.00 признанной выручки, а тикет. Кто-то должен выяснить, какому клиенту и какому счёту он относится, прежде чем закроется отчётный период.

При небольших объёмах это просто раздражает. При объёмах платформы это целый отдел. Движки сопоставления оценивают подходящие счета по сумме, дате и нечёткому совпадению текста назначения; всё, что не удалось определить, уходит в очередь к человеку. А причина сбоя структурная: когда два подписчика платят одинаковую сумму в один день без назначения, никакой движок их не различит — информации, которая их отличала бы, в платеже изначально не было.

Один IBAN на плательщика: идентификация по построению

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

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

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

Когда каждый плательщик платит на свой IBAN, входящий платёж может означать только одно. Задача сопоставления не решается — она перестаёт существовать.

Где на самом деле лежат деньги

Под капотом на каждую валюту приходится ровно один основной счёт. Виртуальные IBAN выпускаются из диапазонов, выделенных под программу, и каждое поступление на любой из них зачисляется на основной счёт. Не нужно вести балансы по плательщикам и нет вечерних джобов, которые перегоняют средства с тысяч мелких счетов на один: консолидация происходит за счёт маршрутизации, а не дополнительных переводов, которые потом пришлось бы сверять отдельно.

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

Чем виртуальный IBAN не является

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

Возвраты приходят с указанием причины

Платежи не только поступают. Счета закрываются, банки отклоняют зачисления, плательщики отзывают переводы. Когда счёт для сбора один, возврат превращается в маленькое расследование: какой платёж вернулся, чей он был и нужно ли отменять проводку, с которой он был сопоставлен.

В программе vIBAN возврат — это данные. Он приходит с кодом причины, фиксируется событием payment.returned по тому же виртуальному IBAN, что и исходное зачисление, и получает отдельную строку в выписке. Вы знаете, чей платёж вернулся и почему, ещё до того, как кто-то заведёт тикет. Возвраты становятся строками для обработки, а не загадками, которые нужно разгадывать.

Очередь исключений вместо команды сопоставления

Ни одна система не сверяет сто процентов чего бы то ни было. Поступления приходят на закрытые vIBAN. Случаются дубликаты. Кто-то и как-то платит прямо на основной счёт. Цель не в том, чтобы исключить исключения, а в том, чтобы они были редкими и поддавались подсчёту. В демо Protocore vIBAN 99.6% поступлений сверяются автоматически; остальные попадают в очередь на проверку с полной историей плательщика, так что работа с исключением начинается с контекста, а не с банковской выписки и таблицы.

Эта разница меняет команду. Операции сопоставления растут вместе с объёмом платежей: больше поступлений — больше неопознанных — больше людей. Процесс обработки исключений растёт вместе с объёмом исключений, а его архитектура уже свела к нулю. Оставшиеся люди разбирают настоящие аномалии, а не перепечатывают назначения платежей. В нашем стеке эта очередь живёт в Protocore Center (/products/center) — операционной консоли, где каждое привилегированное действие требует указать причину и попадает в журнал аудита.

Массовый выпуск, теги назначения, платформы

Схема «один IBAN на плательщика» работает, только если выпуск IBAN ничего не стоит. Арендодатель с дюжиной жильцов может выпустить vIBAN вручную, а маркетплейс, подключающий тысячи продавцов, — нет. Поэтому выпуск — массовая операция. В демо vIBAN CSV-файл с 2,400 плательщиков проходит валидацию, показывает предпросмотр IBAN в каждой строке и выпускается одним действием: 2,400 плательщиков, одна операция, между ними — этап проверки.

Теги назначения разделяют потоки на уровне адреса: аренда здесь, подписки там, выплаты маркетплейса — отдельным потоком. Отчёт по назначению становится фильтром, а не проектом, а у каждого vIBAN есть собственная выписка — в CSV или PDF, — тогда как основной счёт остаётся единым источником истины. Когда плательщик уходит, его vIBAN закрывается: история сохраняется, а адрес перестаёт принимать новые зачисления.

Место в платёжном стеке

Виртуальные IBAN — это инфраструктура приёма платежей. Они дают входящим банковским переводам то, что у карточных платежей было всегда: идентификацию, встроенную в сам платёж, а не вписанную рядом. В экосистеме Protocore заказы Gateway с оплатой переводом содержат ссылки на vIBAN, а Center обрабатывает исключения, которые остаются после сопоставления. На странице продукта /products/viban разобран весь цикл — выпуск, передача, сопоставление, исключения, отчёты — на тех же демо-данных, что и здесь.

И честная граница применимости: если вы принимаете несколько переводов в месяц, хватит соглашения о назначении платежа и десяти минут бухгалтерской работы. Виртуальные IBAN окупаются там, где из-за объёмов сопоставление стало процессом: реестры аренды, сбор подписок, маркетплейсы — везде, где вопрос «кто вам заплатил» звучит тысячи раз в месяц.