Правило первого лица: выплата третьему лицу это отдельная функция

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

Правило первого лица

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

Фаундеры читают это как противодействие, а это не оно. Это границы лицензии и продукта. Счёт построен под то, чтобы хранить и двигать собственные деньги владельца, а платёж третьему лицу это другая регулируемая деятельность с другими обязанностями.

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

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

Почему сбор и выплаты оказываются у разных провайдеров

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

Поэтому разделение сбора и выплат между двумя провайдерами это стандартная архитектура в вертикалях с массовыми выплатами, а не признак серой схемы. Тот, кто говорит, что серьёзная сетка гоняет оба плеча через один счёт, такой сетки не строил.

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

Массовой выдачи именных счетов физическим лицам не существует

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

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

Отдельно учитывайте разницу между виртуальным счётом и именным сегрегированным. Первый открывается за считанные дни, второй занимает от одной до трёх недель, и по нему каждая операция может проходить дополнительную проверку. Контрагент, которому нужны реквизиты на ваше имя, виртуальный счёт не примет, поэтому срок надо планировать по тому типу счёта, который вам реально нужен для расчётов.

Именно последнее недооценивают. Проверка никуда не исчезает, она переезжает к вам. Вы должны быть готовы быстро и по запросу показать, кто каждый получатель, по какому договору ему платят и как вы установили его личность. Если не можете, риском становится сама выплатная рельса, и на первой же проверке провайдер отнесётся к ней именно так.

Как это выглядит, когда построено нормально

• Счёт сбора на операционной компании под расчёты от контрагентов, с потоком, заявленным так, как он выглядит на самом деле.
• Отдельный провайдер выплат на регион, выбранный по фиксированному тарифу за перевод, который подходит множеству мелких платежей, а не по красивой ставке конвертации.
• Онбординг подрядчиков на вашей стороне: договор, личность, налоговый статус и платёжные реквизиты, привязанные к проверенному человеку.
• Жёсткое внутреннее правило: реквизиты получателя совпадают с проверенной личностью. Выплата на счёт друга или родственника это ровно та проблема третьего лица, которую вы обходили стороной, и попадёт она в ваше досье.
• Заранее согласованный путь эскалации по возвращённой или придержанной выплате: кто у провайдера отвечает и в какой срок.
• Второе выплатное отношение в вашем крупнейшем коридоре, потому что закрытие одной рельсы это вопрос времени.

Вопросы на первый звонок

• Этот счёт платит третьим лицам и по какому разрешению?
• Может ли он принимать от третьих лиц или только от проверенного владельца?
• Можно ли вывести фиат на счёт, отличный от того, откуда деньги пришли?
• Какие данные о получателях вы ожидаете от меня и в каком виде будете их запрашивать?
• Тариф фиксированный за перевод и какой потолок на транзакцию у каждой локальной рельсы?
• Вы делаете в этих странах ещё и приём платежей или только выплаты?

Фаундеры теряют месяцы, считая, что операционный счёт справится с выплатами, и неделями согласовывая это с провайдером, который структурно не может. Решение по любому пункту остаётся за провайдером, но какие вопросы задать и когда, зависит только от вас.