Abbiamo parlato più volte di quanto Bitcoin possa beneficiare all'utente finale, le persone "normali" che altrimenti sarebbero (e sono) alla balia delle istituzioni e dei loro capricci.
Un argomento che invece non è stato mai affrontato è se Bitcoin può beneficiare al settore bancario. Per capirlo, è prima necessario capire come le banche gestiscono i movimenti di danaro tra di loro, e di conseguenza cosa significano sigle come "swift".
Ne approfitto quindi per pubblicare la traduzione dell'articolo "A simple explanation of how money moves around the banking system [4]", da parte dell'amico Aga.
di Richard Gendal Brown1
Recentemente su Twitter sono circolati moltissimi messaggi riguardanti una singola transazione di circa 150 mila Bitcoin, equivalenti a oltre 147 milioni di 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.
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.
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.
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 è 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:
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:
Una piccola nota: la procedura descritta fin'ora non è esattamente quello che avviene al giorno d'oggi, poiché soppiantato dai metodi spiegati più sotto ma era necessario descriverla in quanto è la base per comprendere i prossimi paragrafi.
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 [5]2 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 ed impedisce di capirlo.
Fermi tutti. Riepiloghiamo.
Rimangono ancora molti aspetti da analizzare, perché esistono ancora dei problemi seri: il rischio, la 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 [6]3, 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.
Questa possibilità taglia drasticamente i costi e la richiesta di liquidità, ed aggiunge un nuovo componente al nostro diagramma:
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.
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 RTGS4 (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 banche presso la banca centrale.
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 sterline. 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.
Traduzione di Aga per il Portico Dipinto [7].
Collegamenti:
[1] http://ilporticodipinto.it/category/classificazione-articoli/bitcoin
[2] http://ilporticodipinto.it/category/classificazione-articoli/moneta
[3] http://ilporticodipinto.it/category/classificazione-articoli/settore-bancario
[4] http://gendal.wordpress.com/2013/11/24/a-simple-explanation-of-how-money-moves-around-the-banking-system/
[5] http://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication
[6] http://en.wikipedia.org/wiki/BACS
[7] http://ilporticodipinto.it
[8] http://it.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication
[9] http://en.wikipedia.org/wiki/Real_Time_Gross_Settlement