Обезличенный матчинг встречных платёжных потоков: как устроена маршрутизация трансграничных B2B-расчётов без движения денег через границу

Александр Сарычев, технический руководитель платформы MultiFlow

Зачем это читать

Если вы когда-нибудь пытались оплатить из России услугу зарубежной компании или, наоборот, принять оплату от российского клиента, находясь в Таиланде или Индонезии, вы знаете, что «перевод денег» превратился в задачу со многими неизвестными. В этой статье я расскажу, как мы решили её не ускорением перевода, а отказом от самого перевода там, где он не нужен: платформа соединяет встречные заявки бизнесов из разных стран и закрывает их взаимозачётом, а через границу идёт только разница. Ниже - архитектура, алгоритм выбора маршрута и честный список того, что ещё не решено.

Откуда взялась задача

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

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

Что делает платформа, а чего не делает

Важно сразу обозначить границы. Платформа не принимает деньги на себя и не является финансовым агентом. Расчёты между партнёрами идут по их собственным лицензированным каналам; платформа предоставляет технологию: приём заявки, обезличивание, подбор встречной заявки или канала, контроль исполнения, отчётность. Юридическое лицо зарабатывает на подписке за использование программного обеспечения. Это не юридическая тонкость, а архитектурное ограничение: оно определяет, какие данные мы храним, какие операции выполняем и за что отвечаем.

Архитектура в одном абзаце

Серверная часть - PHP 8.3 и Laravel 12, клиентская - Vue 3 (одностраничные приложения кабинета партнёра, административной панели и публичной страницы оплаты), хранение - MariaDB, фоновые задачи - Laravel Queue, события в реальном времени - Laravel Reverb по WebSocket. Внешние платёжные каналы подключаются через слой адаптеров по единому контракту: создать платёж, обработать обратный вызов, проверить статус, вернуть. Фабрика адаптеров создаёт нужный по идентификатору - новый канал добавляется одним классом без изменения бизнес-логики. Исходящие вебхуки партнёрам подписываются HMAC-SHA256 и доставляются с повтором. Логи разнесены по каналам (payments, payouts, providers, kyc, webhooks, security) с посуточной ротацией - это спасает, когда нужно понять, что происходило с конкретной заявкой в 3 часа ночи по Бангкоку.

Жизненный цикл заявки

1. Приём. Партнёр создаёт заявку через кабинет или API: сумма, валюта, страна получателя, метод, требуемое время. Клиент партнёра видит страницу оплаты - например, QR-код Системы быстрых платежей с таймером.

2. Обезличивание и нормализация. Заявка теряет привязку к конкретному партнёру для целей подбора и превращается в набор признаков: пара валют, диапазон суммы, коридор, метод, срочность, риск-профиль. Это принципиально: алгоритм не должен «предпочитать» знакомых.

3. Формирование пула кандидатов. Матчинговый модуль отбирает встречные заявки (противоположно направленные по паре стран/валют) и доступные каналы исполнения с учётом лимитов и операционных окон.

4. Скоринг. Каждому кандидату считается рейтинг по совокупности критериев - о них ниже.

5. Исполнение. Выбранный маршрут исполняется: либо взаимозачёт со встречной заявкой (локальные обязательства закрываются внутри стран, через границу идёт только разница), либо канал провайдера.

6. Контроль и переоркестрация. Если канал отказал или не ответил в окно - заявка не падает, а возвращается в очередь; отказавший маршрут временно понижается (о предохранителе ниже); подбирается следующий кандидат. Партнёр ничего не пересоздаёт.

Скоринг маршрута: почему не «список провайдеров»

Самый частый вопрос: чем это отличается от каскада провайдеров, который есть в любом платёжном шлюзе? Разница в том, откуда берутся веса. В классическом каскаде приоритеты статичны: провайдер А первый, Б второй, переключение по коду ошибки. У нас рейтинг кандидата пересчитывается на каждую заявку по фактическим данным:

доля успешных исполнений именно по этому коридору (пара валют, страна, диапазон суммы) за скользящее окно - не «у провайдера в целом», а «у провайдера на рублях в баты на суммах 20-50 тысяч»;

доступная ёмкость партнёра прямо сейчас: лимиты минус уже занятое;

фактическая стоимость маршрута - заявленная комиссия, скорректированная историей (бывает, что заявленный тариф и реальный итог расходятся);

фактическая скорость - не SLA из договора, а медиана и хвост по истории;

риск-профиль контрагента и корреляция с прошлыми инцидентами.

Итог - для каждого партнёра и каждого коридора существует живой показатель эффективности, который меняется после каждой операции. Сегодня это взвешенная модель на агрегатах по временным окнам; следующий шаг - калиброванная модель вероятности успешного исполнения (градиентный бустинг на табличных признаках), которую мы валидируем на отложенной по времени выборке и сравниваем с правилами в A/B-режиме. Цель - прирост доли операций, исполненных с первой попытки, не менее чем на 10 процентных пунктов.

Взаимозачёт: где именно экономятся деньги

Если в течение окна ожидания есть встречный поток по паре стран, обязательства закрываются локально. Пример: тайская школа должна получить оплату от российского ученика, а тайский импортёр должен заплатить российскому поставщику. Через платформу российский ученик платит российскому поставщику внутри России, тайский импортер платит школе внутри Таиланда, а через границу идёт только разница между двумя суммами. Меньше трансграничных операций - меньше комиссий, времени и точек отказа.

Инженерная сложность здесь не в бухгалтерии, а во времени. Чем дольше ждём встречную заявку, тем выше коэффициент взаимозачёта, но тем дольше ждёт клиент. Мы решаем это адаптивным окном: его размер зависит от текущей плотности потока по коридору. На плотных коридорах окно короткое, на редких - заявка быстрее уходит в канал провайдера, чем ждёт пару. Параметры подбираем дискретно-событийным моделированием на исторических потоках, целевой ориентир - не ниже 40 процентов объёма во взаимозачёте без роста среднего времени исполнения выше 15 минут.

Предохранитель и переоркестрация

Каналы отказывают, и отказывают неравномерно: провайдер, который час назад работал идеально, может лечь на десять минут. Поэтому у нас нет статичной таблицы резервных маршрутов. При отказе маршрут получает штраф к рейтингу и на заданный интервал выводится из подбора (тот самый circuit breaker), затем возвращается с пониженным приоритетом и восстанавливает его успешными исполнениями. Очередь резервных маршрутов - это просто следующие по актуальному рейтингу кандидаты, пересчитанные в момент отказа. Заявка при этом для клиента не меняет идентификатор и не требует повторного оформления.

Контур проверок

Каждая заявка проходит скрининг по санкционным и стоп-спискам, правила по суммам, частоте и географии, поведенческую оценку. Решение - принять, отправить на ручную проверку, заблокировать. Риск-профиль контрагента - один из входов в скоринг маршрутизации, поэтому высокорисковые каналы отсекаются автоматически. Режим верификации клиента настраивается на уровне отдельной кассы партнёра: по документам, по чеку, по документу с чеком - под юрисдикцию и тип бизнеса. Отдельная задача на ближайший год - снизить долю ложных срабатываний правил без потери полноты: сейчас типовые «банковские» сценарии дают много шума на трансграничных B2B-паттернах, и мы проверяем гибридную схему с моделью аномалий и графовыми признаками связей между партнёрами.

Что уже работает и в каких цифрах

Платформа в эксплуатации 24/7 с начала 2026 года. Подключены партнёры из 12 стран, пять каналов исполнения, порядка ста операций в сутки, среднее время исполнения - до 15 минут, доля успешных операций - от 84 до 93 процентов в зависимости от партнёра, почти 98 процентов клиентов проходят верификацию. Кодовая база - около 58 тысяч строк, из них 23 тысячи серверной логики; программа зарегистрирована в Роспатенте.

Чего мы ещё не решили

Холодный старт новых коридоров: пока по направлению нет истории, скоринг опирается на признаки похожих коридоров, и первые операции идут «на ощупь».

Взаимозачёт статистически устойчив только при достаточной плотности потока; на редких коридорах он почти не срабатывает.

Задержанная разметка инцидентов: причина отказа часто становится известна через дни, и модель учится с лагом.

Объяснимость решений: партнёр иногда спрашивает, почему его заявка пошла таким маршрутом, - нужен человекочитаемый разбор вклада признаков.

Если вы решали похожие задачи - маршрутизация по фактическим исходам, взаимозачёт с временными окнами, снижение шума финмониторинга - буду рад обсудить в комментариях.