Travel Rule ломает онбординг не из-за KYC, а из-за плохой передачи данных

Travel Rule ломает онбординг не из-за KYC, а из-за плохой передачи данных

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

Что важно: для переводов между VASP не хватает только формы с именем. Нужна проверка, что данные матчатся с транзакцией и уходят в нужный endpoint. Если поля обрезаются, форматируется только часть имени или теряется адрес получателя, перевод зависает на ручной проверке.

На практике ломают процесс три вещи:
— разные форматы имени в UI, CRM и Travel Rule-модуле;
— отсутствие нормализации адресов и memo/tag;
— пустые или «серые» поля по стране, документу, типу аккаунта.
Из-за этого один и тот же пользователь может пройти KYC, но не пройти передачу данных для контрагента.

Что передавать в первую очередь: стабильный customer ID, полное имя, статус верификации, кошелёк или account identifier, network, asset, amount, originator/beneficiary data и метку, кто именно инициировал перевод. Для B2B-процессов полезно хранить ещё и trace ID, чтобы быстро сводить инциденты между провайдерами.

Делайте Travel Rule как часть payment flow, а не как отдельный юридический экран: тогда меньше ручных стопов, меньше возвратов и проще масштабировать онрамп без лишнего трения.