Blockchain para Impacto Social: Lecciones de Construir con UNICEF

En 2021, Xcapit recibió inversión del UNICEF Innovation Fund para construir una billetera blockchain no custodial orientada a la inclusión financiera en América Latina. En ese momento yo venía de Deloitte, donde medíamos el éxito con métricas conocidas — TIR, EBITDA, participación de mercado. Lo que siguió fue una de las experiencias intelectualmente más exigentes de mi vida profesional, y no principalmente por razones técnicas. El desafío fue entender qué significaba el éxito cuando tus usuarios son familias en zonas rurales del Perú que acceden a las finanzas digitales por primera vez.

Esa pregunta — ¿qué significa el éxito acá? — es la tensión central en la tecnología de impacto social. Es una pregunta que el software empresarial casi nunca tiene que responder de la misma manera. El software empresarial falla cuando no reduce costos o no incrementa ingresos. El software de impacto social puede fallar incluso cuando es ampliamente adoptado, si esa adopción no se traduce en una mejora real en la vida de las personas. Esta distinción cambia todo sobre cómo construís, cómo medís y cómo tomás decisiones de producto.

Diseñar para el Mundo Real, No para el Entorno de Demo

La primera lección que internalizamos — de manera dolorosa — fue que diseñar para entornos de baja conectividad no es un feature flag que agregás al final del desarrollo. Es una restricción arquitectónica que debe regir cada decisión desde el día uno. Las comunidades andinas del Perú, donde parte de nuestro piloto se ejecutó, tienen conectividad móvil que cae a 2G o desaparece por completo en muchas zonas. Los flujos estándar de onboarding en Web3 asumen una conexión a banda ancha estable, un smartphone con al menos 4GB de RAM y un usuario cómodo navegando múltiples pantallas de confirmación. Ninguno de esos supuestos se cumplía.

Reconstruimos el flujo de onboarding tres veces. La primera versión era técnicamente correcta y completamente inutilizable. La segunda era más simple pero aún requería una conexión a internet estable para completar la generación de la billetera y el resguardo de la frase semilla. La tercera versión — la que realmente funcionó en las pruebas de campo — guardaba en caché el proceso de generación de la billetera de forma local, almacenaba la tarea de resguardo de la frase semilla como una acción recuperable sin conexión, y reducía la transferencia de datos del camino crítico a menos de 50 kilobytes. Esto permitía que los usuarios iniciaran el proceso en un momento de conectividad y completaran las partes sensibles en casa, a su propio ritmo.

La capa de interacción de billetera basada en SMS que piloteamos en Perú merece mención especial. Una parte significativa de la población objetivo usaba teléfonos básicos o smartphones de gama baja donde instalar una app era impracticable por restricciones de almacenamiento. Construimos un canal de interacción paralelo usando USSD y SMS que permitía a los usuarios consultar saldos, iniciar transferencias y recibir notificaciones sin la app. Esto no era ingeniería glamorosa. Requería integrarse con APIs de telecomunicadoras locales mal documentadas e inestables, construir una máquina de estados para flujos SMS de múltiples pasos, y testear extensamente con teléfonos reales de campo en lugar de emuladores. Pero expandió significativamente la población alcanzable.

Las Métricas de Inclusión Financiera que Realmente Importan

El marco de reporting de UNICEF nos empujó hacia métricas de resultado que, honestamente, no habríamos priorizado por nuestra cuenta. El fondo no solo quería saber cuántas billeteras habíamos creado. Quería evidencia de cambio en el comportamiento financiero. ¿Estaban ahorrando de manera más consistente? ¿Accedían a remesas a menor costo que los canales tradicionales? ¿Estaban construyendo historiales crediticios que eventualmente los conectaran al sistema de préstamos formal? Estas preguntas requieren datos longitudinales, lo que implica mantener relaciones con los usuarios a lo largo del tiempo — un modelo operativo completamente diferente al de las métricas típicas de adquisición SaaS.

Nos asociamos con ONGs locales para la recolección de datos en terreno. Realizamos entrevistas estructuradas a los 3 y 6 meses. Aprendimos que las tasas de activación de billetera — que se ven genial en una presentación — te dicen casi nada sobre el impacto. De 100 usuarios que activaron una billetera, alrededor de 60 realizaron al menos una transacción en la primera semana. Al mes tres, solo unos 30 seguían activos. Al mes seis, unos 15. Esos 15 usuarios, sin embargo, mostraron indicadores significativos de cambio en el comportamiento financiero: patrones de ahorro más consistentes, menor dependencia de prestamistas informales, y puntajes más altos en evaluaciones de educación financiera. También eran más propensos a recomendar el producto a familiares, lo que se convirtió en nuestro principal mecanismo de crecimiento.

La lección acá es incómoda para los fundadores orientados al crecimiento: tu número principal será el que peor se vea. La activación es fácil; la retención es difícil; el cambio de comportamiento es aún más difícil. UNICEF nos empujó a medir las cosas difíciles, y esa disciplina nos hizo construir un mejor producto. Cuando dejamos de optimizar para la activación y empezamos a optimizar para la retención a seis meses, todo cambió — el contenido de onboarding, la estrategia de notificaciones, el modelo de soporte, las alianzas que priorizamos.

Navegar la Complejidad Regulatoria sin un Departamento de Compliance

La regulación de blockchain en América Latina durante 2021 a 2023 estaba, para decirlo diplomáticamente, evolucionando rápidamente. Perú, Colombia, Argentina y Brasil tenían marcos diferentes — algunos explícitos, algunos implícitos, todos sujetos a cambios. Como startup operando en múltiples jurisdicciones con una billetera no custodial (es decir, nunca mantuvimos fondos de usuarios directamente), existíamos en una zona gris que era simultáneamente liberadora y generadora de ansiedad. El modelo no custodial fue una decisión deliberada para reducir el riesgo regulatorio: estábamos construyendo infraestructura, no tomando depósitos.

El desafío práctico fue explicar esta distinción a reguladores que, comprensiblemente, eran cautelosos con todo lo relacionado a blockchain después de varios colapsos de alto perfil en el sector. Invertimos tiempo significativo en educación regulatoria — no lobbying, sino intercambio genuino de conocimiento con equipos de bancos centrales y organismos reguladores financieros. Esto era inusual para una startup de nuestro tamaño, pero el respaldo institucional de UNICEF abría puertas que de otro modo habrían permanecido cerradas. La lección: las relaciones regulatorias no son solo una función de compliance; son un activo estratégico, especialmente cuando se opera en mercados emergentes con tecnología novedosa.

También aprendimos de la manera difícil que los requisitos de compliance en distintas jurisdicciones no se apilan de manera ordenada. Los estándares KYC en Argentina exigen verificación biométrica que los usuarios peruanos no podían completar de manera práctica. Los umbrales de monitoreo de transacciones difieren en órdenes de magnitud entre mercados. Construir un producto que sea compliant en todos lados implica construir al estándar más restrictivo en todos lados, lo que puede socavar la misión de inclusión financiera al agregar fricción exactamente para los usuarios a los que intentás llegar. Eventualmente construimos una capa de compliance con conciencia jurisdiccional que aplicaba los requisitos correctos según la ubicación del usuario, pero esto agregó tres meses a nuestro cronograma y una carga de mantenimiento continua significativa.

Qué Requiere Realmente la Certificación de Bien Público Digital

Obtener la certificación de Bien Público Digital (BPD) de la Digital Public Goods Alliance fue un hito que perseguimos deliberadamente, y el proceso fue más riguroso de lo que anticipamos. El estándar BPD evalúa nueve criterios: relevancia para los Objetivos de Desarrollo Sostenible, licencias abiertas, titularidad clara, independencia de plataforma, documentación, extracción de datos, protección de privacidad, adherencia a estándares de privacidad y — crucialmente — evidencia de no causar daño. Este último criterio es genuinamente difícil de satisfacer en el espacio blockchain, donde el consumo de energía y los casos de uso especulativos son preocupaciones legítimas.

Nuestra solicitud de BPD nos exigió documentar no solo qué hacía el producto, sino cómo se tomaban las decisiones sobre el producto, quién podía contribuir al codebase y cómo se incorporaba el feedback de la comunidad. El requisito de código abierto implicó hacer nuestro codebase completamente público, lo que requirió una auditoría de seguridad para asegurarnos de no exponer vulnerabilidades. Los criterios de protección de privacidad exigieron documentar nuestros flujos de datos con un nivel de detalle que la mayoría de las startups solo alcanza cuando un regulador lo exige. El proceso tomó aproximadamente cuatro meses desde la solicitud inicial hasta la certificación.

Lo interesante de la certificación BPD es que nos hizo mejores construyendo software, no solo mejores logrando una credencial. Los estándares de documentación requeridos para la certificación son genuinamente útiles para los equipos de ingeniería. Los requisitos de privacidad por diseño que exige la certificación son valiosos para todos los usuarios, no solo para las poblaciones que originalmente apuntábamos. Cuando luego construimos productos empresariales para clientes fuera del espacio de impacto social, los hábitos y prácticas de la certificación BPD mejoraron esos productos también.

Qué Pueden Aprender las Empresas de los Proyectos de Impacto Social

Presenté estas lecciones en UNGA78 y SXSW ante audiencias compuestas principalmente por líderes empresariales, no por fundadores de startups. La pregunta que escucho con más frecuencia es: ¿qué puede aprender una organización grande, con procesos estructurados y recursos sustanciales, de una startup que intenta llegar a comunidades no bancarizadas en los Andes? La respuesta es más de lo que esperarías.

Primero, diseñar con restricciones produce mejores productos. Cuando ingeniás un sistema para funcionar en entornos de baja conectividad y baja alfabetización, construís algo más robusto y más accesible para todos. Los sistemas empresariales fallan rutinariamente en casos borde — interrupciones de red, problemas de compatibilidad de navegador, brechas de accesibilidad para usuarios con discapacidades — precisamente porque esos casos borde no fueron considerados restricciones de diseño primarias. El diseño para impacto social te obliga a hacer que los casos borde sean centrales.

Segundo, medir lo que es genuinamente difícil de medir crea accountability. Las organizaciones empresariales miden lo fácil — ingresos, costos, tiempo de ciclo. Las métricas más difíciles — bienestar de los empleados, confianza del cliente, calidad de la relación a largo plazo — son a menudo las que predicen el desempeño sostenible. El marco de UNICEF nos obligó a construir infraestructura de medición para métricas difíciles. La disciplina se transfiere directamente a contextos empresariales.

• Diseñá para tus usuarios más exigentes primero: los entornos de baja conectividad y baja alfabetización producen productos más robustos para todos
• Medí el cambio de comportamiento, no la actividad: las activaciones de billetera y las vistas de página te hablan de adquisición, no de impacto
• Construí infraestructura de compliance desde el inicio: incorporar privacidad por diseño y compliance con conciencia jurisdiccional después cuesta de tres a cinco veces más
• Las relaciones regulatorias son activos estratégicos: involucrá a los reguladores como socios en el intercambio de conocimiento, no solo como guardianes
• La disciplina de código abierto mejora todos los productos: los estándares de documentación y seguridad requeridos para la certificación BPD también mejoran los codebases internos
• La retención a seis meses revela la verdad del producto: las métricas de activación son vanidad en contextos de impacto social; las métricas de cambio de comportamiento son la realidad

En Xcapit, las lecciones de nuestra experiencia con el UNICEF Innovation Fund han moldeado cómo abordamos cada proyecto blockchain, ya sea que el cliente sea un organismo multilateral, una empresa de energía o una institución financiera. Si estás evaluando blockchain para tu organización — para impacto social, transparencia en la cadena de suministro o infraestructura financiera — bienvenida la conversación. Explorá nuestros casos de estudio en xcapit.com/case-studies para ver cómo estos principios se aplican en distintas industrias y escalas.