Ce este un IBAN virtual?

Un IBAN virtual (vIBAN) este un cod IBAN real, adresabil, emis dintr-un interval dedicat și rutat într-un singur cont principal. Acceptă plăți ca orice alt IBAN — un plătitor îi trimite un transfer credit SEPA obișnuit din propria bancă — dar nu ține niciun sold al său. Rolul lui este identificarea: pentru că fiecare IBAN virtual este atribuit exact unui plătitor sau unui scop, o plată care sosește pe el spune deja cine a trimis-o și pentru ce este. Banii se concentrează automat în contul principal; IBAN-ul virtual este eticheta de pe plată, nu un al doilea loc în care stau banii.

Această singură proprietate — un IBAN per plătitor — este toată ideea. Ca să vezi de ce merită un articol, pornește de la problema pe care o elimină.

Problema reală: potrivirea banilor cu plătitorii

Imaginează-ți o afacere care încasează prin transfer bancar într-un singur cont: chirii, abonamente, facturi. Fiecare încasare ajunge pe același IBAN, iar singurul indiciu despre cine a plătit este ce a tastat plătitorul în câmpul de referință. Referințele sunt tastate greșit, trunchiate undeva pe lanț sau lăsate complet goale. Un transfer de €49.00 cu o referință stâlcită nu este încă venit recunoscut de €49.00 — este un tichet. Cineva trebuie să afle cărui client și cărei facturi îi aparține înainte să se închidă contabilitatea.

La volum mic, e o bătaie de cap. La volum de platformă, e un departament. Motoarele de potrivire punctează facturile candidate după sumă, dată și text aproximativ de referință; ce nu pot plasa ajunge într-o coadă umană. Iar modul de eșec este structural: când doi abonați plătesc aceeași sumă în aceeași zi fără referință, niciun motor nu îi poate separa — informația care i-ar deosebi nu a fost niciodată în plată, de la bun început.

Un IBAN per plătitor: identitate din construcție

Un program de IBAN virtual inversează schema. În loc să ceri fiecărui plătitor să-și eticheteze corect plata, dai fiecărui plătitor propria adresă. Fiecare chiriaș, abonat sau vânzător de marketplace plătește într-un IBAN care este numai al lui. Câmpul de referință poate fi greșit, gol sau într-un alt alfabet — încasarea tot se identifică singură, pentru că identitatea este purtată, în schimb, de numărul de cont.

Numărul de cont este un purtător mult mai bun decât referința. Un IBAN include propriile cifre de control, așa că un IBAN tastat greșit pică validarea la banca plătitorului înainte ca transferul să fie măcar trimis. O referință tastată greșit trece nestingherită și devine problema ta. Mutarea identității din câmpul de text liber în adresă mută verificarea erorii din back office-ul tău la banca expeditoare.

Pentru plătitor, nimic nu se schimbă: plătește un IBAN din aplicația lui bancară, ca întotdeauna. Toată noutatea este de partea receptorului — plata sosește preetichetată, iar câmpul de referință redevine ceea ce ar fi trebuit să fie dintotdeauna: o notă, nu un sistem de identificare.

Când fiecare plătitor plătește în propriul IBAN, o plată care sosește nu poate însemna decât un singur lucru. Problema potrivirii nu este rezolvată — încetează să existe.

— Protocore · Inginerie de plăți

Unde stau, de fapt, banii

Dedesubt există exact un singur cont principal per monedă. IBAN-urile virtuale sunt emise din intervale dedicate programului, iar fiecare încasare trimisă către oricare dintre ele se decontează în contul principal. Nu există solduri per plătitor de gestionat și nici joburi de colectare la sfârșit de zi care să care fonduri din mii de conturi mici într-unul singur — concentrarea se întâmplă prin rutare, nu prin transferuri suplimentare pe care apoi ar trebui să le reconciliezi la rândul lor.

Tocmai asta face ca un IBAN virtual să fie real, nu un truc. Este adresabil de la orice bancă, se procesează ca orice transfer credit SEPA și apare pe extrasul propriu al plătitorului drept contul pe care l-a plătit. Ce îi lipsește este exact ceea ce târăște după sine un cont complet: un sold al său și un ciclu de viață dincolo de atribuire și retragere.

Ce nu este un IBAN virtual

Nu este un subcont: un subcont ține un sold, are nevoie de alimentare și de retragere de fonduri și înmulțește registrele pe care le operezi. Nu este un număr de referință virtual: acelea tot călătoresc pe câmpul de referință și tot depind de plătitori care copiază corect șiruri de caractere. Și nu este un portofel: nimic nu este stocat pe vIBAN-ul în sine. Este o adresă cu rutare în spate — construcția cea mai îngustă care face ca o plată care sosește să se autoidentifice.

Retururile revin cu un motiv atașat

Plățile nu doar sosesc. Conturi se închid, băncile resping încasări, plătitorii revocă transferuri. Într-o lume cu un singur cont de colectare, un retur este o mică investigație: care plată a revenit, a cui a fost și trebuie desfăcută înregistrarea din registru cu care a fost potrivită?

Într-un program de vIBAN, un retur este dată. Poartă codul său de motiv, sosește ca un eveniment payment.returned pe același IBAN virtual pe care l-a folosit încasarea originală și primește propria evidență pe extras. Știi a cui plată a revenit și de ce, înainte ca cineva să deschidă un tichet. Retururile devin rânduri de procesat, nu mistere de urmărit.

O coadă de excepții, nu o echipă de potrivire

Niciun design nu reconciliază sută la sută din orice. Sosesc încasări pe vIBAN-uri retrase. Apar duplicate. Cineva, cumva, plătește direct în contul principal. Scopul nu este să faci excepțiile imposibile — este să le faci rare și numărabile. În demo-ul vIBAN Protocore, 99.6% dintre încasări se reconciliază automat; restul se așază la coadă pentru revizuire, cu istoricul complet al plătitorului atașat, așa că lucrul la o excepție pornește de la context, nu de la un extras bancar și un tabel.

Această diferență remodelează echipa. O operațiune de potrivire scalează cu volumul de plăți: mai multe încasări, mai multe încasări nepotrivite, mai mulți oameni. Un proces de excepții scalează cu volumul de excepții, pe care designul l-a împins deja spre zero. Oamenii pe care îi păstrezi lucrează anomalii autentice, nu referințe retastate. În stiva noastră, coada aceea trăiește în Protocore Center (/products/center), consola de operare unde fiecare acțiune privilegiată cere un motiv și ajunge într-un jurnal de audit.

Emitere în masă, etichete de scop, platforme

Un IBAN per plătitor funcționează doar dacă emiterea unuia nu costă nimic. Un proprietar cu o duzină de chiriași ar putea genera vIBAN-uri manual; un marketplace care înrolează mii de vânzători nu poate. Așa că emiterea este o operațiune în masă. În demo-ul vIBAN, un CSV cu 2,400 de plătitori se validează, previzualizează un IBAN pe fiecare rând și emite într-o singură acțiune — 2,400 de plătitori, o singură operațiune, cu un pas de revizuire între ele.

Etichetele de scop țin fluxurile separate la nivel de adresă: chiriile aici, abonamentele acolo, plățile de marketplace pe banda lor. Raportarea pe scop devine un filtru, nu un proiect, iar fiecare vIBAN primește propriul extras — CSV sau PDF — în timp ce contul principal rămâne singura linie de adevăr de dedesubt. Când un plătitor pleacă, vIBAN-ul lui este retras: istoricul rămâne, adresa încetează să mai accepte încasări noi.

Unde se așază asta într-o stivă de plăți

IBAN-urile virtuale sunt infrastructură de colectare. Dau transferurilor bancare de intrare ceea ce plățile cu card au avut dintotdeauna — identitate atașată plății în sine, nu tastată alături de ea. În ecosistemul Protocore, comenzile pay-by-transfer din Gateway poartă referințe vIBAN, iar Center lucrează orice excepții lasă în urmă potrivirea. Pagina de produs de la /products/viban parcurge întreaga buclă — emitere, partajare, potrivire, excepție, raportare — pe aceleași date demo folosite aici.

Și o limită onestă: dacă primești o mână de transferuri pe lună, o convenție de referință și zece minute de contabilitate sunt suficiente. IBAN-urile virtuale își merită banii acolo unde volumul a transformat potrivirea într-un proces — chirii în serie, colectări de abonamente, marketplace-uri — oriunde întrebarea cine te-a plătit este pusă de mii de ori pe lună.