Che cos'è un IBAN virtuale?
Un IBAN virtuale (vIBAN) è un vero International Bank Account Number, indirizzabile, emesso da un intervallo dedicato e instradato su un unico conto master. Accetta pagamenti come qualsiasi altro IBAN (il pagatore gli invia un normale bonifico SEPA dalla propria banca), ma non ha un saldo proprio. Il suo compito è l'identificazione: poiché ogni IBAN virtuale è assegnato a un solo pagatore o a un solo scopo, un pagamento in arrivo dice già chi lo ha inviato e per cosa. Il denaro si concentra automaticamente nel conto master; l'IBAN virtuale è l'etichetta del pagamento, non un secondo luogo in cui il denaro risiede.
Questa sola proprietà, un IBAN per pagatore, è l'idea centrale. Per capire perché merita un articolo, partiamo dal problema che elimina.
Il vero problema: associare gli importi ai pagatori
Immaginate un'azienda che incassa via bonifico su un unico conto: affitti, abbonamenti, fatture. Ogni accredito arriva sullo stesso IBAN e l'unico indizio su chi ha pagato è ciò che il pagatore ha scritto nella causale. Le causali vengono digitate male, troncate lungo il percorso o lasciate vuote. Un bonifico da €49.00 con una causale illeggibile non è ancora €49.00 di ricavi riconosciuti: è un ticket. Qualcuno deve capire a quale cliente e a quale fattura appartiene prima della chiusura dei conti.
Con volumi bassi è un fastidio. Con i volumi di una piattaforma diventa un reparto. I motori di matching assegnano un punteggio alle fatture candidate in base a importo, data e testo approssimato della causale; ciò che non riescono ad abbinare finisce in una coda manuale. E il limite è strutturale: quando due abbonati pagano lo stesso importo lo stesso giorno senza causale, nessun motore può distinguerli, perché l'informazione che li separerebbe non era mai stata nel pagamento.
Un IBAN per pagatore: identità by design
Un programma di IBAN virtuali ribalta l'impostazione. Invece di chiedere a ogni pagatore di etichettare correttamente il proprio pagamento, si dà a ogni pagatore un indirizzo proprio. Ogni inquilino, abbonato o venditore di un marketplace paga su un IBAN che è solo suo. La causale può essere sbagliata, vuota o in un altro alfabeto: l'accredito si identifica comunque da solo, perché l'identità è portata dal numero di conto.
Il numero di conto è un vettore molto migliore della causale. Un IBAN include le proprie cifre di controllo, quindi un IBAN digitato male non supera la validazione presso la banca del pagatore prima ancora che il bonifico parta. Una causale sbagliata passa senza problemi e diventa un problema vostro. Spostare l'identità dal campo di testo libero all'indirizzo sposta il controllo degli errori dal vostro back office alla banca di chi paga.
Per il pagatore non cambia nulla: paga un IBAN dalla propria app bancaria, come sempre. Tutta la novità sta dal lato di chi riceve: il pagamento arriva già etichettato e la causale torna a essere ciò che avrebbe sempre dovuto essere, una nota e non un sistema di identificazione.
Quando ogni pagatore paga sul proprio IBAN, un pagamento in entrata può significare una cosa sola. Il problema del matching non viene risolto: smette di esistere.
Dove si trova davvero il denaro
Sotto il cofano c'è esattamente un conto master per valuta. Gli IBAN virtuali sono emessi da intervalli dedicati al programma e ogni accredito inviato a uno qualsiasi di essi viene regolato sul master. Non ci sono saldi per pagatore da gestire né job di sweep a fine giornata che spostano fondi da migliaia di piccoli conti a uno solo: la concentrazione avviene per instradamento, non con trasferimenti aggiuntivi che dovreste poi riconciliare a loro volta.
È anche ciò che rende un IBAN virtuale una cosa reale e non un trucco. È indirizzabile da qualsiasi banca, viene regolato come qualsiasi bonifico SEPA e compare nell'estratto conto del pagatore come il conto che ha pagato. Gli manca esattamente ciò che si porta dietro un conto vero: un saldo proprio e un ciclo di vita che vada oltre l'assegnazione e la dismissione.
Cosa non è un IBAN virtuale
Non è un sottoconto: un sottoconto ha un saldo, richiede alimentazione e svuotamento e moltiplica i registri da gestire. Non è un numero di riferimento virtuale: quelli viaggiano ancora nella causale e dipendono ancora dal fatto che i pagatori copino correttamente le stringhe. E non è un wallet: nulla è custodito sul vIBAN stesso. È un indirizzo con un instradamento dietro, il costrutto più essenziale che renda un pagamento in entrata auto-identificante.
Gli storni tornano con il motivo allegato
I pagamenti non fanno solo entrare denaro. I conti si chiudono, le banche rifiutano gli accrediti, i pagatori richiamano i bonifici. In un mondo con un solo conto di incasso, uno storno è una piccola indagine: quale pagamento è tornato indietro, di chi era e la registrazione contabile a cui era abbinato va stornata?
In un programma vIBAN, uno storno è un dato. Porta con sé il codice del motivo, arriva come evento payment.returned sullo stesso IBAN virtuale usato dall'accredito originale e ha una propria riga nell'estratto conto. Sapete di chi era il pagamento tornato indietro, e perché, prima che qualcuno apra un ticket. Gli storni diventano righe da gestire, non misteri da inseguire.
Una coda di eccezioni, non un team di matching
Nessun sistema riconcilia il cento per cento di qualcosa. Arrivano accrediti su vIBAN dismessi. Capitano i duplicati. Qualcuno, in qualche modo, paga direttamente il conto master. L'obiettivo non è rendere impossibili le eccezioni, ma renderle rare e contabili. Nella demo vIBAN di Protocore il 99.6% degli accrediti si riconcilia automaticamente; il resto finisce in revisione con l'intera storia del pagatore allegata, così lavorare un'eccezione parte dal contesto e non da un estratto conto e un foglio di calcolo.
Questa differenza ridisegna il team. Un'attività di matching cresce con il volume dei pagamenti: più accrediti, più accrediti non abbinati, più persone. Un processo di eccezioni cresce con il volume delle eccezioni, che il design ha già spinto verso zero. Le persone che restano lavorano anomalie vere, non causali da ridigitare. Nel nostro stack quella coda vive in Protocore Center (/products/center), la console operativa in cui ogni azione privilegiata richiede una motivazione e finisce in un audit log.
Emissione massiva, tag di scopo, piattaforme
Un IBAN per pagatore funziona solo se emetterne uno non costa nulla. Un proprietario con una dozzina di inquilini potrebbe creare i vIBAN a mano; un marketplace che inserisce migliaia di venditori no. Per questo l'emissione è un'operazione massiva. Nella demo vIBAN, un CSV di 2,400 pagatori viene validato, mostra in anteprima un IBAN su ogni riga e viene emesso con una sola azione: 2,400 pagatori, una operazione, con un passaggio di revisione nel mezzo.
I tag di scopo tengono separati i flussi a livello di indirizzo: gli affitti qui, gli abbonamenti là, i payout del marketplace nella loro corsia. Il reporting per scopo diventa un filtro e non un progetto, e ogni vIBAN ha il proprio estratto conto, in CSV o PDF, mentre il conto master resta sotto la sola fonte di verità. Quando un pagatore se ne va, il suo vIBAN viene dismesso: la storia resta, l'indirizzo smette di accettare nuovi accrediti.
Dove si colloca in uno stack di pagamento
Gli IBAN virtuali sono infrastruttura di incasso. Danno ai bonifici in entrata ciò che i pagamenti con carta hanno sempre avuto: l'identità allegata al pagamento stesso, non digitata accanto. Nell'ecosistema Protocore, gli ordini pay-by-transfer di Gateway portano riferimenti vIBAN e Center gestisce le eccezioni che il matching lascia indietro. La pagina prodotto /products/viban percorre l'intero ciclo (emettere, condividere, abbinare, gestire le eccezioni, fare reporting) sugli stessi dati demo usati qui.
E un limite onesto: se ricevete una manciata di bonifici al mese, una convenzione sulle causali e dieci minuti di contabilità bastano. Gli IBAN virtuali si ripagano dove il volume ha trasformato il matching in un processo: canoni di locazione, incassi di abbonamenti, marketplace, ovunque la domanda «chi mi ha pagato?» venga posta migliaia di volte al mese.
Hai un sistema da costruire?
Raccontaci il problema. Torneremo con un'architettura e un piano.