Czym jest wirtualny IBAN?

Wirtualny IBAN (vIBAN) to prawdziwy, adresowalny międzynarodowy numer rachunku bankowego, wydawany z dedykowanej puli i kierowany na jedno konto główne. Przyjmuje płatności jak każdy inny IBAN — płatnik wysyła na niego zwykły przelew SEPA ze swojego banku — ale nie przechowuje własnego salda. Jego zadaniem jest identyfikacja: ponieważ każdy wirtualny IBAN jest przypisany dokładnie do jednego płatnika lub celu, wpłata, która na niego trafia, już mówi, kto ją wysłał i czego dotyczy. Środki same gromadzą się na koncie głównym; wirtualny IBAN jest etykietą płatności, a nie drugim miejscem, w którym leżą pieniądze.

Ta jedna cecha — jeden IBAN na płatnika — to cała idea. Żeby zobaczyć, dlaczego warto poświęcić jej artykuł, zacznijmy od problemu, który usuwa.

Prawdziwy problem: dopasowanie pieniędzy do płatników

Wyobraź sobie firmę, która zbiera przelewy na jedno konto: czynsz, subskrypcje, faktury. Każda wpłata trafia na ten sam IBAN, a jedyną wskazówką, kto zapłacił, jest to, co płatnik wpisał w polu tytułu. Tytuły bywają wpisane z błędem, ucięte gdzieś po drodze albo puste. Przelew na €49.00 z nieczytelnym tytułem to jeszcze nie €49.00 rozpoznanego przychodu — to zgłoszenie do obsłużenia. Ktoś musi ustalić, do którego klienta i której faktury należy, zanim zamkną się księgi.

Przy małej skali to uciążliwość. Przy skali platformy to cały dział. Silniki dopasowujące oceniają kandydatów na faktury po kwocie, dacie i rozmytym tekście tytułu; czego nie potrafią przypisać, trafia do kolejki dla człowieka. A problem jest strukturalny: gdy dwóch subskrybentów płaci tę samą kwotę tego samego dnia bez tytułu, żaden silnik ich nie rozróżni — informacji, która by ich odróżniała, nigdy nie było w płatności.

Jeden IBAN na płatnika: tożsamość z założenia

Program wirtualnych IBAN-ów odwraca projekt. Zamiast prosić każdego płatnika o poprawne opisanie przelewu, dajesz każdemu własny adres. Każdy najemca, subskrybent czy sprzedawca na marketplace płaci na IBAN, który należy tylko do niego. Pole tytułu może być błędne, puste albo w innym alfabecie — wpłata i tak sama się identyfikuje, bo tożsamość niesie numer rachunku.

Numer rachunku jest znacznie lepszym nośnikiem niż tytuł. IBAN zawiera własne cyfry kontrolne, więc błędnie wpisany numer nie przejdzie walidacji w banku płatnika, zanim przelew w ogóle zostanie wysłany. Błędnie wpisany tytuł przechodzi bez problemu i staje się Twoim problemem. Przeniesienie tożsamości z pola dowolnego tekstu do adresu przenosi kontrolę błędów z Twojego back office do banku nadawcy.

Dla płatnika nic się nie zmienia: płaci na IBAN z aplikacji bankowej, tak jak zawsze. Cała nowość jest po stronie odbiorcy — płatność przychodzi już opisana, a pole tytułu wraca do roli, jaką miało od początku: notatki, a nie systemu identyfikacji.

Gdy każdy płatnik płaci na własny IBAN, wpłata przychodząca może znaczyć tylko jedno. Problem dopasowania nie zostaje rozwiązany — przestaje istnieć.

Gdzie naprawdę leżą pieniądze

Pod spodem jest dokładnie jedno konto główne na walutę. Wirtualne IBAN-y są wydawane z pul przeznaczonych dla programu, a każda wpłata na dowolny z nich księgowana jest na koncie głównym. Nie ma sald per płatnik do zarządzania ani wieczornych zadań, które przesuwałyby środki z tysięcy małych kont na jedno — koncentracja następuje przez routing, a nie przez dodatkowe przelewy, które trzeba by potem osobno uzgadniać.

To też sprawia, że wirtualny IBAN jest prawdziwy, a nie sztuczką. Jest adresowalny z każdego banku, rozlicza się jak każdy przelew SEPA i widnieje na wyciągu płatnika jako rachunek, na który zapłacił. Brakuje mu dokładnie tego, co ciągnie za sobą pełne konto: własnego salda i cyklu życia wykraczającego poza przypisanie i wycofanie.

Czym wirtualny IBAN nie jest

To nie subkonto: subkonto ma saldo, wymaga zasilania i wypłat oraz mnoży księgi, które musisz prowadzić. To nie wirtualny numer referencyjny: ten nadal jedzie w polu tytułu i nadal zależy od tego, czy płatnicy poprawnie przepiszą ciąg znaków. I to nie portfel: nic nie jest przechowywane na samym vIBAN-ie. To adres z routingiem za nim — najwęższa konstrukcja, dzięki której wpłata przychodząca sama się identyfikuje.

Zwroty wracają z przyczyną

Płatności nie tylko przychodzą. Konta się zamykają, banki odrzucają wpłaty, płatnicy wycofują przelewy. W świecie jednego konta zbiorczego zwrot to małe śledztwo: która płatność wróciła, czyja była i czy zapis księgowy, do którego ją dopasowano, trzeba cofnąć?

W programie vIBAN zwrot to dane. Niesie kod przyczyny, trafia jako zdarzenie payment.returned na ten sam wirtualny IBAN, którego użyła pierwotna wpłata, i ma własną pozycję na wyciągu. Wiesz, czyja płatność wróciła i dlaczego, zanim ktokolwiek otworzy zgłoszenie. Zwroty stają się wierszami do obsłużenia, a nie zagadkami do rozwiązywania.

Kolejka wyjątków zamiast zespołu dopasowującego

Żaden projekt nie uzgadnia stu procent czegokolwiek. Wpłaty trafiają na wycofane vIBAN-y. Zdarzają się duplikaty. Ktoś, jakoś, płaci bezpośrednio na konto główne. Celem nie jest wykluczenie wyjątków, lecz sprawienie, by były rzadkie i policzalne. W demo vIBAN od Protocore 99.6% wpłat uzgadnia się automatycznie; reszta trafia do przeglądu z pełną historią płatnika, więc obsługa wyjątku zaczyna się od kontekstu, a nie od wyciągu bankowego i arkusza kalkulacyjnego.

Ta różnica zmienia zespół. Operacja dopasowywania rośnie wraz z wolumenem płatności: więcej wpłat, więcej niedopasowanych, więcej ludzi. Proces wyjątków rośnie wraz z liczbą wyjątków, którą projekt już zepchnął w stronę zera. Ludzie, których zostawiasz, zajmują się prawdziwymi anomaliami, a nie przepisywaniem tytułów. W naszym stosie ta kolejka żyje w Protocore Center (/products/center), konsoli operacyjnej, w której każda uprzywilejowana akcja wymaga podania powodu i trafia do logu audytowego.

Masowe wydawanie, tagi celu, platformy

Jeden IBAN na płatnika działa tylko wtedy, gdy wydanie go nic nie kosztuje. Wynajmujący z tuzinem lokatorów mógłby tworzyć vIBAN-y ręcznie; marketplace, który onboarduje tysiące sprzedawców, już nie. Dlatego wydawanie jest operacją masową. W demo vIBAN plik CSV z 2,400 płatnikami przechodzi walidację, pokazuje podgląd IBAN-u w każdym wierszu i jest wydawany jedną akcją — 2,400 płatników, jedna operacja, krok przeglądu pomiędzy.

Tagi celu oddzielają przepływy na poziomie adresu: czynsz tu, subskrypcje tam, wypłaty marketplace we własnym torze. Raportowanie według celu staje się filtrem, a nie projektem, a każdy vIBAN ma własny wyciąg — CSV lub PDF — podczas gdy konto główne pozostaje jedynym źródłem prawdy pod spodem. Gdy płatnik odchodzi, jego vIBAN zostaje wycofany: historia zostaje, a adres przestaje przyjmować nowe wpłaty.

Miejsce w stosie płatniczym

Wirtualne IBAN-y to infrastruktura do przyjmowania wpłat. Dają przelewom przychodzącym to, co płatności kartowe miały zawsze — tożsamość dołączoną do samej płatności, a nie wpisywaną obok niej. W ekosystemie Protocore zamówienia płatne przelewem w Gateway niosą referencje vIBAN, a Center obsługuje wyjątki, które zostawi po sobie dopasowanie. Strona produktu pod adresem /products/viban prowadzi przez cały obieg — wydaj, udostępnij, dopasuj, obsłuż wyjątek, raportuj — na tych samych danych demo, które wykorzystano tutaj.

I uczciwa granica: jeśli przyjmujesz kilka przelewów miesięcznie, wystarczy konwencja tytułów i dziesięć minut księgowania. Wirtualne IBAN-y zwracają się tam, gdzie wolumen zmienił dopasowywanie w proces — zarządzanie czynszami, pobieranie subskrypcji, marketplace — wszędzie tam, gdzie pytanie „kto Ci zapłacił” pada tysiące razy w miesiącu.