Skip to main content
Xcapit
Blog
·11 min di lettura·Antonella PerroneAntonella Perrone·COO

Blockchain per l'Impatto Sociale: Lezioni dalla Collaborazione con UNICEF

blockchainsocial-impactcase-study
Dashboard con metriche di impatto sociale della blockchain, inclusi indicatori di inclusione finanziaria
Misurare l'impatto sociale nei progetti blockchain richiede metriche che vadano oltre il volume delle transazioni — la fiducia finanziaria, l'uso ripetuto e la resilienza economica familiare sono quelle che contano di più

Nel 2021, Xcapit ha ricevuto un investimento dall'UNICEF Innovation Fund per costruire un wallet blockchain non custodiale orientato all'inclusione finanziaria in America Latina. All'epoca avevo appena lasciato Deloitte, dove misuravamo il successo con metriche familiari — IRR, EBITDA, quota di mercato. Ciò che seguì fu una delle esperienze intellettualmente più impegnative della mia vita professionale, e non principalmente per ragioni tecniche. La sfida era capire cosa significasse davvero il successo quando gli utenti sono famiglie nelle zone rurali del Perù che accedono per la prima volta alle finanze digitali.

Quella domanda — cosa significa il successo qui? — è la tensione centrale nella tecnologia ad impatto sociale. È una domanda a cui il software aziendale quasi mai deve rispondere allo stesso modo. Il software aziendale fallisce quando non riduce i costi o non aumenta i ricavi. Il software ad impatto sociale può fallire anche quando è ampiamente adottato, se quell'adozione non si traduce in un miglioramento significativo nella vita delle persone. Questa distinzione cambia tutto: come si costruisce, come si misura e come si prendono le decisioni di prodotto.

Progettare per il Mondo Reale, Non per l'Ambiente di Demo

La prima lezione che abbiamo interiorizzato — con fatica — è che progettare per ambienti a bassa connettività non è un'opzione da aggiungere alla fine dello sviluppo. È un vincolo architetturale che deve governare ogni decisione fin dal primo giorno. Le comunità andine del Perù, dove si è svolto parte del nostro pilota, hanno una connettività mobile che scende a 2G o scompare del tutto in molte aree. I flussi di onboarding standard del Web3 presuppongono una connessione broadband stabile, uno smartphone con almeno 4GB di RAM e un utente a proprio agio nel navigare tra molteplici schermate di conferma. Nessuna di queste assunzioni era valida.

Abbiamo ricostruito il flusso di onboarding tre volte. La prima versione era tecnicamente corretta e completamente inutilizzabile. La seconda era più semplice ma richiedeva ancora una connessione internet stabile per completare la generazione del wallet e il backup della frase seed. La terza versione — quella che ha effettivamente funzionato nelle prove sul campo — memorizzava localmente il processo di generazione del wallet, archiviava il backup della frase seed come azione recuperabile offline e riduceva il trasferimento dati del percorso critico a meno di 50 kilobyte. Questo consentiva agli utenti di avviare il processo durante un momento di connettività e di completare le parti sensibili a casa, nei propri tempi.

Il livello di interazione con il wallet basato su SMS che abbiamo pilotato in Perù merita una menzione speciale. Una parte significativa della popolazione target utilizzava telefoni base o smartphone di fascia bassa dove installare un'app era impraticabile per via delle limitazioni di archiviazione. Abbiamo costruito un canale di interazione parallelo tramite USSD e SMS che permetteva agli utenti di verificare i saldi, avviare trasferimenti e ricevere notifiche senza l'app. Non era ingegneria glamour. Richiedeva l'integrazione con API di telecomunicazioni locali, scarsamente documentate e inaffidabili, la costruzione di una macchina a stati per flussi SMS multi-step e test estensivi con telefoni reali da campo piuttosto che emulatori. Ma ha ampliato significativamente la popolazione raggiungibile.

Le Metriche di Inclusione Finanziaria che Contano Davvero

Il framework di reporting di UNICEF ci ha spinto verso metriche di esito che, onestamente, non avremmo priorizzato autonomamente. Il fondo non voleva solo sapere quanti wallet avevamo creato. Voleva prove di un cambiamento nel comportamento finanziario. Gli utenti stavano risparmiando in modo più costante? Accedevano alle rimesse a costi inferiori rispetto ai canali tradizionali? Stavano costruendo storie creditizie che potessero eventualmente collegarli al credito formale? Queste domande richiedono dati longitudinali, il che presuppone il mantenimento di relazioni con gli utenti nel tempo — un modello operativo completamente diverso dalle tipiche metriche di acquisizione SaaS.

Abbiamo collaborato con ONG locali per la raccolta di dati sul campo. Abbiamo condotto interviste strutturate a 3 e 6 mesi. Abbiamo imparato che i tassi di attivazione del wallet — che appaiono ottimi in una presentazione — dicono quasi nulla sull'impatto. Su 100 utenti che hanno attivato un wallet, circa 60 hanno effettuato almeno una transazione nella prima settimana. Al terzo mese, solo circa 30 erano ancora attivi. Al sesto mese, circa 15. Quei 15 utenti, tuttavia, mostravano indicatori significativi di cambiamento nel comportamento finanziario: schemi di risparmio più costanti, minore dipendenza dai prestatori informali e punteggi più alti nelle valutazioni di alfabetizzazione finanziaria. Erano anche più propensi a raccomandare il prodotto ai familiari, che è diventato il nostro principale meccanismo di crescita.

La lezione qui è scomoda per i fondatori orientati alla crescita: il tuo numero principale sarà quello che appare peggiore. L'attivazione è facile; la retention è difficile; il cambiamento comportamentale è ancora più difficile. UNICEF ci ha spinto a misurare le cose difficili, e quella disciplina ci ha fatto costruire un prodotto migliore. Quando abbiamo smesso di ottimizzare per l'attivazione e abbiamo iniziato a ottimizzare per la retention a sei mesi, tutto è cambiato — i contenuti di onboarding, la strategia di notifica, il modello di supporto, le partnership che abbiamo prioritizzato.

Diagramma del ciclo di vita di un progetto blockchain ad impatto sociale, dal design alla certificazione
I progetti ad impatto sociale attraversano fasi distinte — progettazione del pilota, validazione sul campo, navigazione normativa e certificazione di terze parti — ognuna con competenze diverse

La regolamentazione blockchain in America Latina tra il 2021 e il 2023 era, per dirla diplomaticamente, in rapida evoluzione. Perù, Colombia, Argentina e Brasile avevano framework diversi — alcuni espliciti, alcuni impliciti, tutti soggetti a cambiamenti. Come startup operante in più giurisdizioni con un wallet non custodiale (ovvero, non detenendo mai direttamente i fondi degli utenti), esistevamo in una zona grigia che era al tempo stesso liberatoria e fonte di ansia. Il modello non custodiale era una scelta deliberata per ridurre il rischio normativo: stavamo costruendo infrastruttura, non raccogliendo depositi.

La sfida pratica era spiegare questa distinzione ai regolatori che erano, comprensibilmente, cauti nei confronti di qualsiasi cosa legata alla blockchain dopo diversi crolli di alto profilo nel settore. Abbiamo investito molto tempo nell'educazione normativa — non lobbying, ma una genuina condivisione di conoscenze con i team delle banche centrali e degli enti regolatori finanziari. Questo era insolito per una startup delle nostre dimensioni, ma il sostegno istituzionale di UNICEF ha aperto porte che altrimenti sarebbero rimaste chiuse. La lezione: le relazioni con i regolatori non sono solo una funzione di compliance; sono un asset strategico, soprattutto quando si opera in mercati emergenti con tecnologie innovative.

Abbiamo anche imparato a nostre spese che i requisiti di compliance tra le giurisdizioni non si sommano in modo ordinato. Gli standard KYC in Argentina richiedono la verifica biometrica che gli utenti peruviani non potevano completare praticamente. Le soglie di monitoraggio delle transazioni differiscono di ordini di grandezza tra i mercati. Costruire un prodotto conforme ovunque significa costruire rispettando lo standard più restrittivo ovunque, il che può minare la missione di inclusione finanziaria aggiungendo attrito esattamente per gli utenti che si tenta di raggiungere. Alla fine abbiamo costruito un livello di compliance consapevole della giurisdizione che applicava i requisiti corretti in base alla posizione dell'utente, ma questo ha aggiunto tre mesi alla nostra timeline e un significativo onere di manutenzione continua.

Cosa Richiede Davvero la Certificazione di Bene Pubblico Digitale

Ottenere la certificazione di Bene Pubblico Digitale (BPD) dalla Digital Public Goods Alliance è stato un traguardo perseguito deliberatamente, e il processo è stato più rigoroso di quanto avessimo anticipato. Lo standard BPD valuta nove criteri: rilevanza per gli Obiettivi di Sviluppo Sostenibile, licenze aperte, proprietà chiara, indipendenza dalla piattaforma, documentazione, estrazione dei dati, protezione della privacy, aderenza agli standard sulla privacy e — fondamentalmente — prove di non arrecare danno. Quest'ultimo criterio è genuinamente difficile da soddisfare nel settore blockchain, dove il consumo energetico e i casi d'uso speculativi sono preoccupazioni legittime.

La nostra domanda di BPD ci ha richiesto di documentare non solo cosa facesse il prodotto, ma come venissero prese le decisioni sul prodotto, chi potesse contribuire al codebase e come venisse incorporato il feedback della comunità. Il requisito open-source ha significato rendere il nostro codebase completamente pubblico, il che ha richiesto un audit di sicurezza per garantire di non esporre vulnerabilità. I criteri di protezione della privacy hanno richiesto di documentare i flussi di dati con un livello di dettaglio che la maggior parte delle startup raggiunge solo quando un regolatore lo esige. Il processo ha richiesto circa quattro mesi dalla domanda iniziale alla certificazione.

La cosa interessante della certificazione BPD è che ci ha resi migliori nel costruire software, non solo nel raggiungere una credenziale. Gli standard di documentazione richiesti per la certificazione sono genuinamente utili per i team di ingegneria. I requisiti di privacy-by-design che la certificazione impone sono preziosi per tutti gli utenti, non solo per le popolazioni che stavamo originariamente cercando di raggiungere. Quando successivamente abbiamo costruito prodotti enterprise per clienti al di fuori dello spazio ad impatto sociale, le abitudini e le pratiche derivanti dalla certificazione BPD hanno migliorato anche quei prodotti.

Cosa Possono Imparare le Imprese dai Progetti ad Impatto Sociale

Ho presentato queste lezioni all'UNGA78 e al SXSW di fronte a platee composte principalmente da leader aziendali, non da fondatori di startup. La domanda che sento più spesso è: cosa può imparare una grande organizzazione, con processi strutturati e risorse sostanziali, da una startup che cerca di raggiungere comunità non bancarizzate nelle Ande? La risposta è più di quanto ci si aspetti.

Primo, progettare con i vincoli produce prodotti migliori. Quando si ingegnerizza un sistema per funzionare in ambienti a bassa connettività e bassa alfabetizzazione, si costruisce qualcosa di più robusto e accessibile per tutti. I sistemi aziendali falliscono regolarmente nei casi limite — interruzioni di rete, problemi di compatibilità del browser, lacune di accessibilità per utenti con disabilità — proprio perché quei casi limite non erano stati considerati vincoli progettuali primari. Il design ad impatto sociale ti obbliga a rendere centrali i casi limite.

Secondo, misurare ciò che è genuinamente difficile da misurare crea accountability. Le organizzazioni aziendali misurano ciò che è facile — ricavi, costi, tempi di ciclo. Le metriche più difficili — benessere dei dipendenti, fiducia dei clienti, qualità delle relazioni a lungo termine — sono spesso quelle che predicono le performance sostenibili. Il framework di UNICEF ci ha obbligati a costruire un'infrastruttura di misurazione per metriche difficili. La disciplina si trasferisce direttamente nei contesti aziendali.

  • Progetta prima per gli utenti più esigenti: gli ambienti a bassa connettività e bassa alfabetizzazione producono prodotti più robusti per tutti
  • Misura il cambiamento comportamentale, non l'attività: le attivazioni di wallet e le visualizzazioni di pagina parlano di acquisizione, non di impatto
  • Costruisci l'infrastruttura di compliance fin dall'inizio: aggiungere privacy-by-design e compliance multi-giurisdizionale dopo costa da tre a cinque volte di più
  • Le relazioni con i regolatori sono asset strategici: coinvolgili come partner nella condivisione di conoscenze, non solo come gatekeeper
  • La disciplina open-source migliora tutti i prodotti: gli standard di documentazione e sicurezza richiesti per la certificazione BPD migliorano anche i codebase interni
  • La retention a sei mesi rivela la verità del prodotto: le metriche di attivazione sono vanità nei contesti ad impatto sociale; le metriche di cambiamento comportamentale sono la realtà

In Xcapit, le lezioni della nostra esperienza con l'UNICEF Innovation Fund hanno plasmato il modo in cui affrontiamo ogni progetto blockchain, che il cliente sia un'agenzia multilaterale, un'azienda energetica o un'istituzione finanziaria. Se stai valutando la blockchain per la tua organizzazione — per l'impatto sociale, la trasparenza della supply chain o l'infrastruttura finanziaria — siamo a disposizione per una conversazione. Esplora i nostri casi studio su xcapit.com/case-studies per vedere come questi principi si traducono in diversi settori e scale.

Share
Antonella Perrone

Antonella Perrone

COO

In precedenza presso Deloitte, con formazione in finanza aziendale e business globale. Leader nell'utilizzo della blockchain per il bene sociale, relatrice di spicco a UNGA78, SXSW 2024 e Republic.

Costruiamo qualcosa di grande

IA, blockchain e software su misura — pensato per il tuo business.

Contattaci

Stai costruendo su blockchain?

Tokenizzazione, smart contract, DeFi — li abbiamo realizzati tutti.

Articoli Correlati