Recentemente su Twitter sono circolati moltissimi messaggi riguardanti una singola transazione di circa 150 mila Bitcoin, equivalenti a oltre 147 mila dollari, avvenuta il 23 novembre. I vari tweet/retweet recitavano tutti più o meno: "Transazione da $147m suscita mistero e speculazioni".

Ci furono molti commenti riguardanti quanto sarebbe stata costosa o difficile un'operazione simile nel sistema bancario tradizionale, che potrebbe benissimo essere vero, ma è stato evidenziato anche un altro aspetto: quasi nessuno comprende il funzionamento dei sistemi di pagamento. E più precisamente: se si effettua un bonifico ad un fornitore o un pagamento ad un amico, come transitano i soldi dal proprio conto al loro?

In questo articolo cercherò di spiegare in parole povere le basi del funzionamento di questo sistema, sperando di non semplificare troppo.

Prima di tutto stabiliamo dei punti di partenza.
La cosa più importante che dobbiamo comprendere sui depositi bancari è il debito. Quando si danno i soldi ad una banca, non viene creato un vero deposito. Non esiste un barattolo contenente il denaro, etichettato con il proprio nome. Quello che avviene realmente è l'aver prestato quei soldi alla banca. Diventa un loro debito. Ecco perchè diciamo che i nostri conti sono in credito: la banca ha aumentato il credito nei nostri confronti. Allo stesso modo, se si prelevasse una quantità di denaro maggiore al credito effettivo, la somma eccedente diventa un nostro debito, e un loro credito. Per capire cosa succede quando vengono spostati i soldi, è importante comprendere che ogni conto può essere visto in questi due modi.

Pagare qualcuno che possiede un conto sulla stessa banca.
Incominciamo con il caso più semplice. Immaginiamo che Alice abbia un conto su una banca, ad esempio Barclays. Alice deve pagare £10 ad un amico, Bob, ed anche lui utilizza Barclays. Pagare Bob è semplice: Alice fornisce istruzioni alla banca, addebitando i fondi dal suo conto ed accreditando £10 sul conto di Bob. L'operazione avviene elettronicamente sui sistemi informatici della Barclays ed è tutto estremamente semplice. Nessun soldo viene inviato o ricevuto dalla banca, viene solo aggiornato il bilancio dei loro conti. La banca avrà £10 di credito in meno verso Alice e £10 di credito in più verso Bob. Il bilancio rimane in pareggio e le operazioni rimangono all'interno: possiamo dire che la transazione è fissata sui libri contabili della banca. Le uniche figure coinvolte sono Alice, Bob e Barclays.

Cosa succede se si paga qualcuno ad una banca differente?
Qui è dove le cose diventano interessanti. Immaginiamo che Alice debba pagare Charlie, che ha un conto sulla banca HSBC. Ora c'è un problema: è semplice per la Barclays ridurre il suo credito nei confronti di Alice di £10, ma come possono convincere HSBC a incrementare il credito di Charlie di £10? Perché HSBC dovrebbe accettare di essere in debito di £10 in più rispetto a prima? Non sono un'ente di carità. La risposta è, ovviamente, che se vogliamo che la HSBC conceda a Charlie un credito maggiore, essa dovrà corrispondere a qualcun altro una somma minore.

Chi dovrebbe essere questo "qualcun altro"? Non può essere Alice: non ha alcun rapporto con la HSBC. Per eslcusione, l'unico interlocutore rimasto è la Barclays. E qui arriva il primo colpo di scena. Cosa succederebbe se la HSBC avesse un conto sulla Barclays e la Barclays ne avesse uno sulla HSBC? Potrebbero mantenere dei bilanci reciproci e aggiornarli in modo da far funzionare il tutto.

Ecco come si potrebbe fare:

• La Barclays toglie £10 dal conto di Alice
• La Barclays aggiunge £10 al conto della HSBC sulla Barclays
• La Barclays manda un messaggio alla HSBC informandoli di aver aumentato il bilancio di £10, e di incrementare di £10 quello di Charlie a sua volta.
• La HSBC riceve il messaggio e, garantita dai £10 in più sulla Barclays, può incrementare il bilancio di Charlie.
• Il rapporto tra Alice e Charlie viene sistemato: Alice ha £10 in meno e Charlie ha £10 in più.

Anche tra Barclays e HSBC il rapporto è pareggiato. Prima Barclays era in debito di £10 nei confronti di Alice, ora lo è nei confronti della HSBC. Prima HSBC era in pareggio, ora è in debito di £10 con Charlie e ha un credito di £10 dalla Barclays.

Questo metodo per elaborare i pagamenti è conosciuto come rapporto di corrispondenza tra banche, che facilita i pagamenti tra i loro rispettivi clienti. Secondo alcuni, il rapporto di corrispondenza tra banche comprende solo i casi in cui sono coinvolte valute differenti ma ritengo sia vantaggioso usare questa definizione anche per i casi più semplici come quello dell'esempio.

Funzionerebbe piuttosto bene ma presenta alcuni problemi: evidentemente sarebbe necessario che le due banche avessero un rapporto reciproco diretto, altrimenti non si potrebbero effettuare i pagamenti, o sarebbe necessario farlo transitare attraverso una terza (o quarta!) banca, finché non diventi possibile completare il percorso di accordi bancari tra chi deve pagare e chi deve ricevere i soldi, aumentando sensibilmente il costo e la complessità dell'operazione.

Sarebbe inoltre molto rischioso. Vediamo la situazione dal punto di vista della HSBC. Come risultato di questo pagamento, la loro esposizione nei confronti di Barclays è appena aumentata. Nel nostro esempio è solo di £10 ma se fosse di £150 milioni e la banca corrispondente non fosse Barclays ma un istituto più piccolo, la HSBC avrebbe dei grossi problemi se l'istituto dovesse fallire. Un modo per ovviare a questo inconveniente è di modificare leggermente la procedura: invece di essere Barclays ad accreditare £10 sul conto della HSBC, Barclay potrebbe chiedere alla HSBC di addebitare £10 sul suo conto. In questo modo si potrebbe evitare l'accrescimento dei bilanci interbancari, ma rimangono comunque altri inconvenienti con questo tipo di procedure, alcuni dei quali vedremo tra poco, e comunque l'interconnessione necessaria rappresenta un problema reale.

Una piccola nota: la procedura descritta fin'ora non è esattamente quello che avviene al giorno d'oggi, poiché soppiantato dai metodi spiegati qui sotto ma era necessario descriverla in quanto è la base per comprendere i prossimi paragrafi.

Ma perché complicarsi la vita? Non si può fare tutto semplicemente con gli "SWIFT"?
Quando si parla di sistemi di pagamento, capita spesso di incontrare qualcuno che agita le mani gridando "SWIFT!" pensando di aver chiuso il discorso. Questo comportamento evidenzia quanto probabilmente non conosce ciò di cui sta parlando.

La rete SWIFT esiste per consentire alle banche di scambiare messaggi elettronici tra loro in tutta sicurezza. Uno dei messaggi supportati dalla rete SWIFT è il MT103, il quale permette ad una banca di informare un'altra banca di accreditare del denaro sul conto di uno dei loro clienti, addebitandolo sul conto dell'istituto mittente per pareggiare il bilancio. Si può immaginare di usare il MT103 per implementare l'esempio discusso precedentemente.

Lo scopo dello SWIFT MT103 è quello di inviare soldi tra le due banche, ma è fondamentale comprendere cosa succede dietro le quinte: il messaggio SWIFT è solo un'informazione, lo spostamento dei fondi avviene addebitando e accreditando diversi conti di ogni istituto e si affida al mantenimento dei conti interbancari (sia direttamente, sia tramite banche intermediarie). Sbracciarsi gridando "SWIFT!" serve solo a nascondere la complessità delle operazioni che avvengono realmente e permette di impararlo.

Bene, ho capito, ma cosa si può dire di ACH, EURO1, Faster Payments, BACS, CHAPS, FedWire, Target2, ... ???
Fermi tutti. Riepiloghiamo.

• Abbiamo visto che trasferire denaro tra due conti sulla stessa banca è banale.
• Abbiamo visto come sia possibile inviare soldi tra conti di diverse banche con un abile trucchetto: accordarsi tra banche e mantenere dei conti reciproci.
• Abbiamo visto come le reti elettroniche come SWIFT consentono di inviare messaggi per gestire i flussi di informazioni tra le banche rapidamente, affidabilmente e a costi contenuti.

Rimangono ancora molti aspetti da analizzare, perché esistono ancora dei problemi seri: il rischio, la liquidità e i costi.

I problemi di liquidità e i costi.
Cominciamo a prendere in considerazione i problemi inerenti la liquidità e il costo. Come possiamo risolverli? Innanzitutto dobbiamo constatare che i trasferimenti SWIFT non sono propriamente economici. Se la Barclays deve inviare alla HSBC un messaggio SWIFT ogni volta che Alice deve pagare £10 a Charlie, Alice si troverà degli addebiti non trascurabili sull'estratto conto. C'è comunque un problema ancora peggiore: la liquidità.

Se il sistema di cui abbiamo appena parlato fosse usato nella pratica quotidiana, quanti soldi la Barclays dovrebbe mantenere sui conti di tutte le banche con cui ha rapporti di corrispondenza? Dovrebbero mantenere bilanci di discrete dimensioni su tutte le altre banche in quanto uno dei loro clienti potrebbe in qualsiasi momento inviare dei soldi ad un destinatario con un conto sulla HSBC, la Lloyds, o qualsiasi altra. Si tratta di somme che si sarebbero potute altrimenti investire, prestare o comunque utilizzare in modo produttivo. Possiamo però fare una deduzione interessante: statisticamente esiste la stessa probabilità che il cliente di un'altra banca voglia inviare del denaro ad un cliente della Barclays.

E se tenessimo conto di tutti i pagamenti durante il periodo di un giorno fissandone solo il bilancio?

In questo caso probabilmente le banche potrebbero ridurre notevolmente la quantità di soldi depositata presso tutte le rispettive corrispondenti, in modo da poter sfruttare il proprio denaro in modo più efficiente, abbassando i costi ai clienti e possibilmente passando loro una parte degli utili. Questo modello ha dato origine ai sistemi di assestamento netto posticipato. Nel regno unito si chiama BACS, ma esistono degli equivalenti in tutto il mondo. In questi sistemi i messaggi non vengono scambiati sulla rete SWIFT bensì ad un sistema di gestione centrale che tiene traccia di tutti i pagamenti e, periodicamente, calcola le somme dovute da ogni banca ad ogni altra. In questo modo possono accordarsi autonomamente, trasferendo i soldi da/verso i conti tenuti reciprocamente oppure tramite il sistema RTGS descritto in seguito. Tutti i circuiti di carte di credito possono essere definiti sistemi di assestamento netto posticipato (anche PayPal lo è), in quanto gestiscono tutte le transazioni al loro interno ed inviano periodicamente i resoconti alle banche.

In questo modo sia i costi sia la richiesta di liquidità vengono ridotti enormemente, ma viene coinvolta una nuova figura, l'ente centrale (BACS, EURO1, Cheque, Visa, PayPal, ...).

Questo metodo però introduce un nuovo problema, potenzialmente peggiore: viene persa l'irrevocabilità delle transazioni. Si può effettuare un ordine di pagamento, ma la banca destinata a ricevere i fondi li otterrà solo in un secondo momento, solo quando verranno calcolati i bilanci netti del periodo corrente. La banca ricevente dovrà quindi aspettare poiché rilasciare i fondi al cliente prima di ottenerli non sarebbe prudente. In alternativa si potrebbe accettare il rischio e stornare l'operazione in caso di problemi, il che non rappresenterebbe comunque la soluzione perché il destinatario non potrebbe fare affidamento su quei fondi fino a che la transazione non venisse considerata definitiva.

Si possono ottenere l'irreversibilità della transazione e l'annullamento dei rischi per la controparte?
Qui è dove entra in scena l'ultimo pezzo del puzzle. Nessuno degli approcci che abbiamo descritto è idoneo nelle situazioni dove sia necessario ottenere velocemente il pagamento e che sia irreversibile anche nel caso in cui la banca emittente dovesse successivamente fallire. Queste garanzie sono strettamente necessarie in certi casi, per esempio in un sistema di gestione delle azioni. Nessuno sarebbe disposto a rilasciare 150 milioni di euro in azioni oppure obbligazioni se esiste il sospetto che il pagamento possa non avvenire o possa essere ritirato.

Ciò che è necessario è un sistema come quello descritto all'inizio (Alice paga Bob usando la stessa banca) perché sarebbe veramente veloce, ma che possa funzionare anche quando sono coinvolte più di una banca, e anche quando le somme trasferite diventano enormi.

Sarebbe necessaria una banca che non possa fallire e con la quale tutte le banche abbiano dei rapporti. Una specie di banca intermedia a tutto il sistema. Possiamo anche dargli un nome: potremmo chiamarla banca centrale!

Questo esercizio mentale promuove l'idea di un sistema RTGS (Real-Time Gross Settlement). Se tutte le principali banche di una nazione hanno dei conti interbancari con la banca centrale, possono spostare denaro tra loro semplicemente informando la banca centrale di addebitare un conto o accreditarne un altro, ed è proprio ciò che viene implementato dai sistemi CHAPS, FedWire e Target2 per le Sterline, i Dollari e gli Euro rispettivamente. Questi sitemi permettono lo spostamento di fondi in tempo reale tra i conti tenuti dalle bance presso la banca centrale.

• Real Time: le transazioni avvengono istantaneamente.
• Gross: non viene calcolato un conguaglio periodico (altrimenti non sarebbe istantaneo).
• Settlement: definitivo, non può essere revocato.

Ora il quadro è completo.

Pensavo che questo articolo avesse a che fare con Bitcoin...
Complimenti per esserci arrivato. Ecco la domanda: possiamo introdurre Bitcoin in questo modello?

La mia opinione è che la rete Bitcoin somiglia moltissimo al sistema Real-Time Gross Settlement: non ci sono conguagli, non ci sono relazioni di corrispondenza tra banche, le transazioni non sono revocabili.

La cosa interessante riguardo all'ambiente finanziario tradizionale moderno è che la maggior parte delle transazioni tra privati non avvengono con RTGS. Per esempio nel Regno Unito per i pagamenti elettronici tra persone viene usato il sistema Faster Payment che non è istantaneo. Perché viene usato? Perché le transazioni sono quasi gratuite mentre i pagamenti CHAPS costano circa £25. Molte persone userebbero un sistema RTGS se fosse altrettanto comodo ed economico.

La domanda a cui non abbiamo ancora dato una risposta è quindi: Bitcoin finirà con il somigliare ad un sistema RTGS che gestisce solo grandi trasferimenti? Oppure la sua struttura evolverà (limiti sulla dimensione dei blocchi, canali per i micropagamenti, ecc.) abbastanza velocemente per mantenersi al passo con il progressivo aumento del numero di transazioni, mantenendolo conveniente sia per i grandi trasferimenti sia per i piccoli pagamenti?

La mia idea è che è ancora presto per stabilirlo: credo che Bitcoin cambierà il mondo ma allo stesso tempo non sono convinto che si arriverà ad un mondo dove ogni transazione Bitcoin verrà confermata sulla Blockchain.

---

Questa traduzione è stata pubblicata anche su Il Portico Dipinto.