Ir al contenido

CBDC transfronterizas, privacidad y gobernanza de datos: la parte difícil empieza cuando el piloto funciona

Esta nota fija una tesis concreta, organiza la lectura del tema y deja visible por que el argumento importa ahora.

Introducción

Buena parte de la conversacion publica sobre monedas digitales de banco central sigue detenida en un punto ya conocido: si una CBDC puede modernizar pagos, ampliar inclusion financiera o mejorar trazabilidad. Esa pregunta sigue siendo importante, pero empieza a quedarse corta. Cuando el debate avanza hacia pagos transfronterizos, interoperabilidad regional y plataformas compartidas, aparece una capa bastante mas exigente: ya no se discute solo como digitalizar dinero publico dentro de un pais, sino bajo que reglas varias jurisdicciones aceptarian coordinar infraestructura, acceso, settlement y gobierno de los datos.

Ese desplazamiento importa porque las promesas mas atractivas de una CBDC suelen aparecer justo ahi. Los pagos transfronterizos siguen siendo lentos, caros y operativamente complejos. El esquema de corresponsalia bancaria no desaparecio, pero en varios corredores se volvio mas costoso o mas fragmentado. Por eso documentos como Project mBridge: connecting economies through CBDC o Project Dunbar – International settlements using multi-CBDCs despertaron tanto interes: no prometen solo una mejora local de pagos, sino la posibilidad de reducir fricciones entre monedas, bancos, plataformas y jurisdicciones.

Pero ahi mismo aparece la segunda capa, mucho menos comoda: si una CBDC mejora velocidad y settlement entre paises, tambien obliga a preguntar quien ve que, quien decide que datos son necesarios, bajo que ley se procesan, quien audita a los intermediarios y como se evita que una infraestructura mas eficiente se convierta tambien en una infraestructura mas intrusiva. La nota nueva, entonces, no deberia retomar el tema CBDC solo desde la promesa. Deberia retomar el punto donde el asunto se vuelve institucionalmente mas serio.

La promesa transfronteriza no es solo tecnica

Los documentos mas utiles para abrir esta capa no son los que celebran la palabra innovacion, sino los que describen con precision el problema operativo. Project Dunbar – International settlements using multi-CBDCs parte de una observacion sobria: los pagos transfronterizos suelen pasar por varias capas de intermediacion, tiempos de procesamiento y comisiones acumuladas que terminan trasladandose al usuario final. La idea de una plataforma comun de settlement con varias CBDC busca acortar ese recorrido. En vez de que cada tramo dependa de cuentas corresponsales y reconciliaciones sucesivas, una infraestructura compartida podria permitir transacciones mas directas entre instituciones financieras en distintas monedas.

Project mBridge: connecting economies through CBDC empuja todavia mas esa posibilidad. El proyecto exploro una plataforma multi-CBDC con transacciones de valor real, FX PvP y settlement casi instantaneo entre jurisdicciones participantes. Ese tipo de experimento importa porque muestra que la discusion ya no esta en fase puramente teorica. La pregunta ya no es solo si una arquitectura asi podria existir. La pregunta es bajo que condiciones politicas, regulatorias y juridicas una infraestructura de ese tipo podria escalar sin crear nuevos puntos de conflicto.

Y ahi conviene hacer una distincion clave. Resolver un cuello de botella tecnico no equivale a resolver un problema institucional. Una plataforma comun puede abaratar pagos y mejorar velocidad, si, pero tambien obliga a acordar reglas de acceso, jerarquias de supervision, tratamiento de errores, resolucion de disputas, criterios de cumplimiento y distribucion de responsabilidades cuando participan bancos centrales con mandatos, marcos legales y niveles de autonomia distintos. La capa regional o transfronteriza no es una simple extension de la CBDC domestica. Es otro problema.

La gobernanza regional empieza donde termina el entusiasmo por la interoperabilidad

La palabra interoperabilidad suele usarse como si fuera una virtud suficiente. No lo es. Entre jurisdicciones, interoperabilidad significa decidir quien puede entrar, quien valida, quien liquida, quien observa, quien detiene operaciones sospechosas y bajo que principio se resuelve una tension entre soberania regulatoria y funcionamiento comun de la plataforma.

El propio informe de Dunbar es valioso porque no oculta esa dificultad. Expone que los desafios criticos pasan por gobernanza, acceso y fronteras jurisdiccionales. En otras palabras: la discusion seria no es solo como conectar monedas, sino como conectar autoridades sin borrar su autonomia. Esa es una tension mucho mas interesante que la narrativa facil de pagos mas rapidos.

El caso de mBridge va en la misma direccion. A medida que el proyecto avanzo hacia una etapa de minimum viable product, hizo falta construir un rulebook y un marco legal especifico para una plataforma descentralizada compartida, tal como explica Project mBridge reached minimum viable product stage. Ese detalle deberia ocupar mas espacio en la discusion publica. Cuando una infraestructura de pagos transfronterizos necesita un libro de reglas propio, deja de ser solo tecnologia. Se convierte en arquitectura institucional multinivel.

Hay por lo menos tres preguntas que ninguna plataforma comun puede esquivar:

  1. quien puede acceder y bajo que licencia institucional;
  2. que datos circulan, se retienen o se comparten entre participantes;
  3. que autoridad prevalece cuando aparecen errores, sospechas, conflictos regulatorios o pedidos de informacion.

Por eso una nota nueva sobre CBDC y capa regional no deberia vender la integracion como una consecuencia natural del progreso tecnico. Deberia plantear algo mas exigente: una plataforma transfronteriza puede mejorar mucho ciertos corredores de pago, pero solo si los paises participantes aceptan coordinar reglas, supervision y criterios de acceso sin caer ni en una integracion simbolica ni en una asimetria silenciosa donde algunos fijan estandares y otros solo se adaptan.

Privacidad: la pregunta seria no es si habra datos, sino quien podra usarlos

La segunda gran capa que merece una nota propia es la privacidad. Y tambien ahi conviene apartarse del lenguaje facil. Decir que una CBDC protegera la privacidad no alcanza. Lo que importa es la arquitectura concreta de datos: que informacion se genera, quien puede verla, durante cuanto tiempo se conserva, bajo que causales puede abrirse, quien supervisa ese acceso y que margen real queda para que el usuario no sea convertido en un sujeto permanentemente legible.

En este terreno, la referencia mas util para abrir la discusion es Digital euro and privacy, del European Central Bank. El valor de ese documento no esta en que cierre el debate, sino en que lo formula bien. Habla de privacy by design, de pagos offline con niveles de privacidad similares al efectivo, de pseudonimizacion y de limites al uso comercial de los datos sin consentimiento explicito. Tambien deja claro que una parte del acceso a informacion seguiria en manos de intermediarios obligados a cumplir con normas de AML y financiamiento del terrorismo. Ese matiz es importante: privacidad no significa opacidad total. Significa disenar una frontera justificable entre vigilancia necesaria, cumplimiento legal y proteccion efectiva de la vida economica de los usuarios.

Eso mismo vuelve mas interesante la capa de gobernanza. En una CBDC, la privacidad no se juega solo en el software ni en el discurso del banco central. Se juega en la relacion entre banco central, intermediarios, reguladores, autoridades judiciales y reglas de acceso a la informacion. Si el banco central no puede vincular directamente pagos con identidad, pero los intermediarios si concentran suficientes datos para perfilar conducta economica, entonces la discusion no se resuelve diciendo que el sistema es publico. Lo que importa es donde queda el poder informacional real.

El problema se vuelve mas serio cuando esta capa se cruza con la dimension transfronteriza. Cada mejora en visibilidad operativa puede parecer una mejora de cumplimiento. Pero tambien puede ampliar la superficie de datos accesible para mas autoridades, mas intermediarios y mas sistemas de control. Por eso una CBDC regional no deberia evaluarse solo por costo y velocidad. Deberia evaluarse tambien por el tipo de poder informacional que crea y por la calidad institucional de los limites que se impone a si misma.

Gobernanza de datos: donde una CBDC puede volverse servicio publico o infraestructura de vigilancia

La expresion gobernanza de datos suele sonar demasiado administrativa para un problema que en realidad es politico. Una CBDC crea o reorganiza una infraestructura donde circulan registros de pagos, validaciones, conversiones, alertas y trazas operativas. La pregunta central es si esa infraestructura se diseña con minimizacion de datos, reglas de acceso estrictas, auditoria independiente y limites claros de uso, o si queda abierta a ampliaciones funcionales posteriores que terminan expandiendo el alcance del monitoreo economico.

En una escala domestica, ese problema ya es serio. En una escala transfronteriza, lo es mucho mas. Si una plataforma comun conecta varias jurisdicciones, aparece un mapa de preguntas incomodas: que datos se comparten entre participantes, con que base legal, bajo que estandar de proteccion, quien define equivalencias regulatorias y que pasa cuando una autoridad quiere ver mas de lo que otra considera razonable. La eficiencia transfronteriza puede ser una mejora enorme. Pero sin una gobernanza muy precisa, tambien puede producir una nueva concentracion de poder sobre los flujos y los historiales de pago.

Por eso conviene sacar la privacidad del lugar decorativo en el que suele quedar. No es un agregado reputacional para hacer aceptable una CBDC. Es una condicion de legitimidad. Si los ciudadanos perciben que una moneda digital publica mejora la trazabilidad estatal pero no protege de forma creible la intimidad economica, la adopcion puede resentirse incluso si la tecnologia funciona. Y si la adopcion se resiente, la promesa de eficiencia o inclusion pierde parte de su valor politico.

Que conviene poder evaluar antes de llamar exito a un piloto regional

Si la capa tecnica ya demostro que puede funcionar, la evaluacion seria cambia de lugar. Ya no alcanza con celebrar velocidad, settlement o ahorro de friccion. Hay que mirar que clase de orden institucional deja realmente armado el piloto.

  1. quien entra a la infraestructura y con que reglas de acceso;
  2. que datos quedan visibles para cada actor y bajo que base legal;
  3. como se auditan errores, excepciones y pedidos extraordinarios de informacion;
  4. que margen real de soberania conserva cada jurisdiccion cuando aparece un conflicto.

Sin esa lectura, un piloto puede parecer un exito operativo y seguir siendo una solucion institucional debil. Esa diferencia es la que esta nueva etapa del debate no deberia esconder.

Que no conviene prometer cuando el piloto ya funciono

  • No conviene prometer que un piloto tecnicamente exitoso ya resolvio la arquitectura institucional: demostrar settlement no equivale a resolver acceso, jurisdiccion, supervision ni resguardo de datos.
  • No conviene prometer solucion total para pagos internacionales: una plataforma transfronteriza puede mejorar costos, tiempos y settlement, pero sigue dependiendo de acuerdos juridicos, capacidades regulatorias y confianza entre autoridades.
  • No conviene prometer interoperabilidad siempre virtuosa: puede abaratar y ordenar, pero tambien puede exportar asimetrias institucionales o generar dependencia respecto de marcos definidos por pocos actores.
  • No conviene prometer privacidad por simple declaracion: si no hay minimizacion de datos, auditoria independiente, limites de acceso y reglas claras para intermediarios, la promesa queda en el nivel del slogan.
  • No conviene prometer que eficiencia y libertad economica avanzan siempre juntas: a veces una infraestructura mas eficiente tambien amplia capacidad de observacion y control.

Que deberia quedar claro en una lectura rapida

Si la nota esta bien planteada, un lector deberia poder salir de una lectura rapida con cuatro respuestas concretas antes de discutir detalles tecnicos.

  1. si el piloto resolvio solo settlement o tambien un marco de gobernanza defendible;
  2. que actores pueden ver, retener o pedir datos dentro de la arquitectura compartida;
  3. que parte de la soberania regulatoria sigue intacta y cual exige coordinacion explicita;
  4. por que la privacidad depende del diseno institucional y no de una promesa abstracta.

Esa sintesis no reemplaza el desarrollo largo. Lo vuelve mas extraible. Permite que la tesis principal aparezca con menos friccion para lectores, buscadores y sistemas de respuesta que primero necesitan ubicar rapido el criterio central de la nota.

Conclusión

Una nueva nota sobre CBDC vale la pena precisamente porque el debate ya puede ser mas exigente que hace unos años. La pregunta no es solo si una moneda digital publica mejora pagos domesticos. La pregunta es que ocurre cuando esa infraestructura quiere volverse regional, transfronteriza y mas intensiva en datos.

En ese punto, los documentos mas utiles no permiten ni utopia ni rechazo automatico. Permiten una lectura mas dura y mas interesante: una CBDC puede abrir mejoras concretas en pagos internacionales y en organizacion monetaria, pero solo si su arquitectura regional y su gobernanza de datos resisten un examen institucional serio. La parte dificil, en realidad, empieza cuando el piloto funciona.

Y ahi es donde una CBDC deja de ser solo una promesa de modernizacion. Pasa a ser una decision sobre distribucion de poder regulatorio, sobre limites al poder informacional y sobre la clase de infraestructura monetaria que una sociedad esta dispuesta a considerar legitima. La prueba relevante ya no es solo si la plataforma liquida. La prueba relevante es si el orden institucional que deja atras merece confianza duradera.

Fuentes consultadas

  1. BIS Innovation Hub – Project mBridge
  2. ECB – Digital euro
  3. Financial Stability Board – Central bank digital currency

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *