Какво е виртуален IBAN?

Виртуалният IBAN (vIBAN) е истински, адресируем международен номер на банкова сметка, издаден от отделен диапазон и насочен към една главна сметка. Приема плащания като всеки друг IBAN – платецът изпраща обикновен SEPA кредитен превод към него от собствената си банка, – но няма собствена наличност. Задачата му е идентификацията: тъй като всеки виртуален IBAN е свързан с точно един платец или една цел, постъпилото по него плащане вече показва кой го е изпратил и за какво е. Парите се събират в главната сметка автоматично; виртуалният IBAN е етикетът върху плащането, а не второ място, където стоят парите.

Именно това свойство – един IBAN за всеки платец – е цялата идея. За да разберем защо заслужава цяла статия, ще започнем с проблема, който премахва.

Същинският проблем: свързването на парите с платците

Представете си бизнес, който събира вземания с банков превод по една сметка: наеми, абонаменти, фактури. Всяко постъпление идва по един и същ IBAN, а единствената следа кой е платил е онова, което платецът е написал в полето за основание. Основанията се объркват, орязват се някъде по веригата или просто липсват. Превод от €49.00 със замазано основание още не е €49.00 признат приход – той е задача за разчистване. Някой трябва да установи на кой клиент и коя фактура принадлежи, преди да се затворят books.

При малък обем това е досада. При обем на платформа е цял отдел. Системите за съпоставяне оценяват кандидат-фактури по сума, дата и приблизително текстово съвпадение на основанието, а всичко, което не могат да разпознаят, отива в опашка за хора. Проблемът е структурен: когато двама абонати платят една и съща сума в един и същи ден без основание, никоя система не може да ги различи – информацията, която би ги разграничила, никога не е била част от плащането.

Един IBAN за всеки платец: идентичност по построение

Програмата за виртуални IBAN обръща логиката. Вместо да искате от всеки платец да озаглави плащането си правилно, давате на всеки собствен адрес. Всеки наемател, абонат или продавец в маркетплейс плаща по IBAN, който е само негов. Основанието може да е грешно, празно или на друга азбука – постъплението пак се идентифицира само, защото идентичността се носи от номера на сметката.

Номерът на сметката е много по-добър носител от основанието. IBAN включва собствени контролни цифри, затова сгрешен IBAN не минава валидация в банката на платеца още преди преводът да бъде изпратен. Сгрешеното основание минава необезпокоявано и става ваш проблем. Преместването на идентичността от свободния текст към адреса премества проверката за грешки от вашия бек офис към банката изпращач.

За платеца нищо не се променя: плаща по IBAN от банковото си приложение, както винаги. Цялата новост е от страната на получателя – плащането пристига вече етикетирано, а основанието отново е това, което винаги е трябвало да бъде: бележка, а не система за идентификация.

Когато всеки платец плаща към собствен IBAN, входящото плащане може да означава само едно. Проблемът със съпоставянето не се решава — той просто престава да съществува.

Къде всъщност стоят парите

Отдолу има точно една главна сметка за всяка валута. Виртуалните IBAN-ове се издават от диапазони, отредени за програмата, и всяко постъпление по тях се сетълва в главната сметка. Няма наличности по платци за управление, нито нощни задачи, които прехвърлят средства от хиляди малки сметки в една – концентрацията става чрез маршрутизиране, а не чрез допълнителни преводи, които после трябва да съгласувате сами по себе си.

Точно това прави виртуалния IBAN истински, а не трик. Адресируем е от всяка банка, преминава през клиринг като всеки SEPA кредитен превод и се появява в извлечението на платеца като сметката, по която е платил. Липсва му точно онова, което една пълноценна сметка носи със себе си: собствена наличност и жизнен цикъл отвъд присвояването и закриването.

Какво не е виртуалният IBAN

Не е подсметка: подсметката държи наличност, изисква захранване и източване и умножава счетоводните книги, които поддържате. Не е виртуален референтен номер: те още разчитат на полето за основание и на това платците да преписват правилно низове. И не е портфейл: нищо не се съхранява по самия vIBAN. Това е адрес с маршрутизиране зад него – най-тясната конструкция, която прави входящото плащане самоидентифициращо се.

Връщанията идват с причина

Плащанията не само пристигат. Сметки се закриват, банки отхвърлят постъпления, платци оттеглят преводи. При една събирателна сметка връщането е малко разследване: кое плащане се е върнало, чие е било и трябва ли да се сторнира записът, с който е било съпоставено?

В програма с vIBAN връщането е данни. Носи код на причината, пристига като събитие payment.returned към същия виртуален IBAN, по който е минало първоначалното постъпление, и има собствено място в извлечението. Знаете чие плащане се е върнало и защо, още преди някой да е отворил задача. Връщанията стават редове за обработка, а не загадки за разгадаване.

Опашка за изключения, а не екип по съпоставяне

Никой дизайн не съгласува сто процента от каквото и да е. Постъпления идват по закрити vIBAN-ове. Случват се дубликати. Някой, по някакъв начин, плаща директно по главната сметка. Целта не е изключенията да станат невъзможни, а да са редки и преброими. В демото на Protocore vIBAN 99.6% от постъпленията се съгласуват автоматично; останалите влизат в опашка за преглед с цялата история на платеца към тях, така че работата по изключението започва от контекст, а не от банково извлечение и електронна таблица.

Тази разлика променя екипа. Операцията по съпоставяне расте с обема на плащанията: повече постъпления, повече несъпоставени, повече хора. Процесът за изключения расте с обема на изключенията, който дизайнът вече е свел почти до нула. Хората, които оставате, разглеждат истински аномалии, а не пренаписани основания. В нашия стек тази опашка живее в Protocore Center (/products/center) – операционната конзола, в която всяко привилегировано действие изисква причина и попада в одитен журнал.

Масово издаване, тагове за цел, платформи

Един IBAN за всеки платец работи само ако издаването му не струва нищо. Наемодател с дузина наематели може да създава vIBAN-ове на ръка; маркетплейс, който въвежда хиляди продавачи, не може. Затова издаването е масова операция. В демото на vIBAN CSV файл с 2,400 платци се валидира, показва предварително IBAN на всеки ред и се издава с едно действие – 2,400 платци, една операция, със стъпка за преглед по средата.

Таговете за цел държат потоците разделени на ниво адрес: наеми на едно място, абонаменти на друго, изплащания към продавачи в собствена лента. Отчетите по цел стават филтър, а не проект, и всеки vIBAN получава собствено извлечение – CSV или PDF, – докато главната сметка остава единственият източник на истината отдолу. Когато платец си тръгне, неговият vIBAN се закрива: историята остава, адресът спира да приема нови постъпления.

Къде се вписва в платежния стек

Виртуалните IBAN са инфраструктура за събиране на плащания. Те дават на входящите банкови преводи онова, което картовите плащания винаги са имали — идентичност, вградена в самото плащане, а не въвеждана отделно до него. В екосистемата на Protocore поръчките на Gateway с плащане по превод носят референции към vIBAN, а Center обработва изключенията, които съпоставянето оставя. Страницата на продукта на /products/viban описва целия цикъл — издаване, споделяне, съпоставяне, изключения, отчет — със същите демо данни, използвани тук.

И една честна граница: ако получавате шепа преводи на месец, конвенция за основанията и десет минути счетоводство са напълно достатъчни. Виртуалните IBAN-ове си заслужават там, където обемът е превърнал съпоставянето в процес – наемни портфейли, абонаментно събиране, маркетплейси – навсякъде, където въпросът кой ви е платил се задава хиляди пъти на месец.