Wat is een virtueel IBAN?
Een virtueel IBAN (vIBAN) is een echt, adresseerbaar International Bank Account Number, uitgegeven uit een eigen reeks en gerouteerd naar één hoofdrekening. Je kunt er net als bij elk ander IBAN naartoe betalen — een betaler stuurt vanaf de eigen bank een gewone SEPA-overschrijving — maar er staat zelf geen saldo op. De taak is identificatie: omdat elk virtueel IBAN aan precies één betaler of doel is toegewezen, zegt een binnenkomende betaling al wie hem stuurde en waarvoor. Het geld komt automatisch samen op de hoofdrekening; het virtuele IBAN is het label op de betaling, niet een tweede plek waar het geld staat.
Die ene eigenschap — één IBAN per betaler — is het hele idee. Om te zien waarom dat een artikel waard is, begin je bij het probleem dat het wegneemt.
Het echte probleem: geld aan betalers koppelen
Stel je een bedrijf voor dat per bankoverschrijving int op één rekening: huur, abonnementen, facturen. Elke ontvangst komt op hetzelfde IBAN binnen, en het enige aanknopingspunt voor wie er betaalde is wat de betaler in het betaalkenmerk heeft getypt. Kenmerken worden verkeerd getypt, ergens onderweg afgekapt of helemaal leeggelaten. Een overschrijving van €49.00 met een onleesbaar kenmerk is nog geen €49.00 aan erkende omzet — het is een ticket. Iemand moet uitzoeken bij welke klant en welke factuur het hoort voordat de boeken sluiten.
Bij lage volumes is dit hinderlijk. Bij platformvolumes is het een afdeling. Matchingengines scoren kandidaat-facturen op bedrag, datum en fuzzy kenmerktekst; wat ze niet kunnen plaatsen, gaat naar een handmatige wachtrij. En de oorzaak is structureel: als twee abonnees op dezelfde dag hetzelfde bedrag zonder kenmerk betalen, kan geen engine ze uit elkaar halen — de informatie die ze onderscheidt zat nooit in de betaling.
Eén IBAN per betaler: identiteit door ontwerp
Een programma met virtuele IBAN's draait het ontwerp om. In plaats van elke betaler te vragen de betaling correct te labelen, geef je elke betaler een eigen adres. Elke huurder, abonnee of marktplaatsverkoper betaalt naar een IBAN dat van die betaler alleen is. Het kenmerkveld mag fout zijn, leeg, of in een ander alfabet — de ontvangst identificeert zichzelf toch, want de identiteit zit in het rekeningnummer.
Het rekeningnummer is een veel betere drager dan het kenmerk. Een IBAN bevat eigen controlecijfers, dus een verkeerd getypt IBAN faalt de validatie bij de bank van de betaler nog voordat de overschrijving wordt verstuurd. Een verkeerd getypt kenmerk glipt erdoorheen en wordt jouw probleem. Door de identiteit uit het vrije tekstveld te halen en in het adres te leggen, verschuift de foutcontrole van jouw backoffice naar de verzendende bank.
Voor de betaler verandert er niets: die betaalt een IBAN vanuit de bankapp, zoals altijd. Alle vernieuwing zit aan de ontvangende kant — de betaling komt vooraf gelabeld binnen, en het kenmerkveld wordt weer wat het altijd had moeten zijn: een notitie, geen identificatiesysteem.
Als elke betaler naar een eigen IBAN betaalt, kan een binnenkomende betaling maar één ding betekenen. Het matchingprobleem wordt niet opgelost — het bestaat niet meer.
Waar het geld daadwerkelijk staat
Eronder bestaat per valuta precies één hoofdrekening. De virtuele IBAN's worden uitgegeven uit reeksen die aan het programma zijn gewijd, en elke ontvangst op een ervan wordt verrekend op de hoofdrekening. Er zijn geen saldi per betaler te beheren en geen dagelijkse sweep-jobs die geld van duizenden kleine rekeningen naar één rekening schuiven — het samenbrengen gebeurt via routering, niet via extra overboekingen die je dan zelf weer zou moeten afletteren.
Dat maakt een virtueel IBAN ook echt in plaats van een truc. Het is vanuit elke bank adresseerbaar, wordt verwerkt als elke SEPA-overschrijving en staat op het eigen afschrift van de betaler als de rekening waarnaar is betaald. Wat het mist is precies wat een volledige rekening met zich meesleept: een eigen saldo en een levenscyclus voorbij toewijzing en opheffing.
Wat een virtueel IBAN niet is
Het is geen subrekening: een subrekening heeft een saldo, moet worden gefund en geleegd, en vermenigvuldigt de grootboeken die je beheert. Het is geen virtueel betaalkenmerk: dat zit nog steeds in het kenmerkveld en hangt er nog steeds van af of betalers tekenreeksen correct overnemen. En het is geen wallet: er wordt niets opgeslagen op het vIBAN zelf. Het is een adres met routering erachter — de smalste constructie die een binnenkomende betaling zelfidentificerend maakt.
Retouren komen terug met een reden
Betalingen komen niet alleen binnen. Rekeningen worden opgeheven, banken weigeren ontvangsten, betalers halen overschrijvingen terug. Met één verzamelrekening is een retour een klein onderzoek: welke betaling kwam terug, van wie was die, en moet de grootboekboeking waaraan ze gekoppeld was worden teruggedraaid?
In een vIBAN-programma is een retour data. Het draagt zijn redencode, komt binnen als payment.returned-event op hetzelfde virtuele IBAN als de oorspronkelijke ontvangst, en krijgt een eigen regel op het afschrift. Je weet van wie de betaling terugkwam, en waarom, voordat iemand een ticket opent. Retouren worden rijen om af te handelen, geen mysteries om na te jagen.
Een uitzonderingswachtrij, geen matchingteam
Geen enkel ontwerp lettert honderd procent van iets af. Er komen ontvangsten binnen op opgeheven vIBAN's. Dubbele betalingen komen voor. Iemand betaalt, op wat voor manier dan ook, direct op de hoofdrekening. Het doel is niet uitzonderingen onmogelijk te maken — maar ze zeldzaam en telbaar te maken. In de Protocore vIBAN-demo wordt 99.6% van de ontvangsten automatisch afgeletterd; de rest komt in de wachtrij voor beoordeling met de volledige historie van de betaler erbij, zodat een uitzondering oppakken begint bij context, niet bij een bankafschrift en een spreadsheet.
Dat verschil verandert het team. Een matchingoperatie schaalt mee met het betalingsvolume: meer ontvangsten, meer niet-gematchte ontvangsten, meer mensen. Een uitzonderingsproces schaalt met het aantal uitzonderingen, en dat heeft het ontwerp al richting nul geduwd. De mensen die je houdt, behandelen echte afwijkingen, geen overgetypte kenmerken. In onze stack staat die wachtrij in Protocore Center (/products/center), de operationsconsole waar elke bevoegde actie een reden vereist en in een auditlog terechtkomt.
Bulkuitgifte, doeltags, platforms
Eén IBAN per betaler werkt alleen als het uitgeven ervan niets kost. Een verhuurder met een dozijn huurders kan vIBAN's met de hand aanmaken; een marktplaats die duizenden verkopers onboardt kan dat niet. Uitgifte is dus een bulkactie. In de vIBAN-demo wordt een CSV met 2,400 betalers gevalideerd, krijgt elke rij een voorbeeld-IBAN en wordt alles in één actie uitgegeven — 2,400 betalers, één bewerking, met een controlestap ertussen.
Doeltags houden stromen op adresniveau gescheiden: huur hier, abonnementen daar, uitbetalingen van de marktplaats op een eigen baan. Rapporteren per doel wordt een filter in plaats van een project, en elk vIBAN krijgt een eigen afschrift — CSV of PDF — terwijl de hoofdrekening eronder de enige bron van waarheid blijft. Als een betaler vertrekt, wordt diens vIBAN opgeheven: de historie blijft, het adres accepteert geen nieuwe ontvangsten meer.
Waar dit in een betaalstack past
Virtuele IBAN's zijn infrastructuur voor ontvangsten. Ze geven inkomende bankoverschrijvingen wat kaartbetalingen altijd al hadden — identiteit die aan de betaling zelf hangt, niet ernaast wordt getypt. In het Protocore-ecosysteem dragen de pay-by-transfer-orders van Gateway vIBAN-referenties, en Center behandelt de uitzonderingen die het matchen overlaat. De productpagina op /products/viban doorloopt de volledige lus — uitgeven, delen, matchen, uitzonderingen, rapporteren — op dezelfde demodata als hier.
En een eerlijke grens: ontvang je een handvol overschrijvingen per maand, dan volstaan een kenmerkafspraak en tien minuten boekhouding. Virtuele IBAN's verdienen zich terug waar volume het matchen tot een proces heeft gemaakt — huurportefeuilles, abonnementsincasso, marktplaatsen — overal waar de vraag wie je betaalde duizenden keren per maand wordt gesteld.
Een systeem te bouwen?
Vertel ons het probleem. Wij komen terug met een architectuur en een plan.