Klient wysłał 5000 USDT, a przelew utknął na dobę — platforma partnerska zażądała imienia i nazwiska nadawcy. Tak właśnie działa Travel Rule dla kantorów krypto: wymóg FATF, by przekazywać dane nadawcy i odbiorcy razem z samym przelewem, gdy kwota przekracza lokalny próg.
Zasada nie jest nowa, ale dopiero w 2026 roku zaczęto ją egzekwować na poważnie — banki i giełdy-partnerzy masowo odcinają VASP-y, które nie potwierdziły zgodności. Dla kantoru to już nie abstrakcyjny punkt compliance, tylko kwestia dostępu do płynności.
Czym jest Travel Rule w prostych słowach
Pomyśl o przelewie bankowym: razem z pieniędzmi zawsze wędruje imię nadawcy i tytuł płatności — to standard SWIFT sprzed dekad. Travel Rule przenosi tę samą logikę do krypto: platforma wysyłająca musi przekazać platformie odbierającej imię, dane portfela i często adres klienta.
Formalnie to Rekomendacja 16 FATF, ale każdy kraj wdraża ją po swojemu: gdzieś próg to 1000 dolarów, gdzieś 1000 euro, a gdzieś dane wymagane są od pierwszej wpłaty.
Kogo to dotyczy i od jakiej kwoty
Zasada obowiązuje przy przelewach między VASP — czyli kantorem a inną licencjonowaną platformą: giełdą, portfelem z KYC, innym kantorem. Przelew na portfel self-hosted formalnie nie podlega Travel Rule, ale regulatorzy coraz częściej oczekują zbierania danych także w tym przypadku, na wszelki wypadek.
- Próg to zwykle 1000 USD/EUR — ale w UE pod MiCA praktycznie zniknął, przepisy obowiązują od pierwszego euro.
- Sprawdzana jest suma przelewów w danym okresie, nie pojedyncza kwota — dzielenie płatności nic nie daje.
- Jeśli kontrahent nie jest zarejestrowany, kantor musi albo odmówić transakcji, albo zebrać dane ręcznie.
Jak dane są przekazywane w praktyce
Nikt nie chce ręcznie wysyłać imion mailem, więc istnieją dedykowane protokoły: TRUST, Notabene, Sygna Bridge, VerifyVASP oraz otwarty standard OpenVASP. Szyfrują one pakiet danych klienta i wiążą go z hashem konkretnej transakcji, dzięki czemu wiadomość trafia do właściwego odbiorcy, a nie gubi się po drodze.
Kantor nie musi budować tego od zera — większość dostawców komunikatów Travel Rule podłącza się jako warstwa API nad już istniejącym systemem compliance, a nie go zastępuje.
Ryzyka i ograniczenia — co może pójść nie tak
Największym bólem głowy jest „sunrise problem”: wiele platform na świecie wciąż nie jest podłączonych do żadnego protokołu, więc przelew może utknąć tylko dlatego, że odbiorca nie ma czym rozszyfrować pakietu.
Drugie ryzyko to fałszywe alarmy — filtr compliance blokuje legalny przelew, bo imię z paszportu nie zgadza się dokładnie z formularzem. Trzecie — prywatność: im więcej danych osobowych krąży między platformami, tym droższy jest wyciek u którejkolwiek z nich.
Częste błędy kantorów przy przygotowaniach
Najczęstszy błąd to odkładanie tematu do pierwszej odmowy banku partnerskiego. W tym momencie negocjacje z nowym partnerem płatniczym trwają tygodniami, a klienci są już wściekli na zawieszone przelewy.
- Poleganie na ręcznej weryfikacji zamiast protokołu — przestaje działać po kilku przelewach dziennie.
- Brak dokumentacji procesu dla regulatora — nie ma czym pokazać audytorowi, że zasada faktycznie jest przestrzegana.
- Ignorowanie przelewów na portfele self-hosted, mimo że bank partnerski i tak żąda tam minimalnych danych.
Podsumowanie
Travel Rule to nie jednorazowe odhaczenie — to infrastruktura, z którą kantor będzie żył na stałe: protokoły się zmieniają, progi różnią się między krajami, a partnerzy zaostrzają wymogi szybciej, niż by się chciało. Rozsądniej jest wbudować wymianę danych w proces od początku, niż łatać go po pierwszym zamrożonym przelewie. Kantor z przemyślaną architekturą compliance i KYC można uruchomić na platformie iEXExchanger.
