Open Finance hace posible que la información circule entre más actores. Pero una conexión, por sí sola, no crea una buena experiencia. El verdadero reto empieza cuando hay que convertir permisos, identidad, acceso y control en reglas que funcionen detrás de cada interacción.

Durante mucho tiempo, gran parte de la conversación sobre Open Finance estuvo centrada en abrir.

Abrir datos. Abrir APIs. Permitir que información que antes permanecía dentro de una entidad pudiera circular, con autorización, hacia otros actores.

Era un paso necesario.

Pero no era el final.

Porque una API puede conectar dos sistemas y, aun así, dejar muchas preguntas sin resolver.

¿Quién está pidiendo acceso? ¿A qué información? ¿Para qué la necesita? ¿Durante cuánto tiempo puede utilizarla? ¿Qué ocurre si el usuario cambia de opinión? ¿Cómo sabemos después qué ocurrió con esos datos?

Ahí Open Finance deja de ser solamente una conversación sobre conexión.

Empieza a ser una conversación sobre operación.

Y esa diferencia importa.

Para el usuario, compartir información puede parecer una acción sencilla. Autorizar. Confirmar. Continuar.

Por detrás, ese gesto tiene que convertirse en algo mucho más preciso.

No basta con saber que una persona dijo “sí”.

Hay que saber a qué dijo que sí.

Los datos muestran por qué ese matiz es relevante. Solo un 21,3% de los usuarios está dispuesto a compartir información financiera para acceder a mejores servicios, mientras un 51,2% no compartiría ninguno de los tipos de información consultados. Además, la disposición cambia según el dato: compartir información financiera, recurrencia de compras, comportamiento o capacidad de consumo no genera el mismo nivel de apertura.

Eso convierte el consentimiento en algo bastante más complejo que una aceptación general.

La apertura no puede funcionar como un permiso indefinido para que cualquier dato circule de cualquier manera.

→ Necesita contexto

→ Qué información

→ Con quién

→ Para qué

Y bajo qué condiciones.

Por eso uno de los cambios más relevantes en la evolución de Open Finance no está únicamente en cuántos datos pueden conectarse, sino en qué tan bien puede administrarse esa conexión una vez que existe.

Los marcos que avanzan en distintos mercados empiezan precisamente a incorporar esta lógica. En Brasil, por ejemplo, las actualizaciones del esquema de Open Finance han reforzado límites operacionales, requisitos técnicos y consentimiento explícito; Argentina también ha incorporado el consentimiento del usuario como condición para compartir información entre distintos actores financieros.

La señal detrás de estos movimientos es más interesante que la regulación en sí.

Abrir información exige reglas capaces de acompañarla.

Porque el dato no deja de ser sensible cuando sale de una entidad.

De hecho, puede volverse más complejo de gobernar cuando empieza a circular entre varias.

Ahí aparece una capa que el usuario probablemente nunca verá completa, pero que define si la experiencia puede funcionar.

La identidad permite reconocer quién está solicitando acceso.

El consentimiento delimita qué fue autorizado.

La infraestructura aplica esos permisos.

Y la trazabilidad permite reconstruir qué ocurrió después.

No son componentes aislados.

Tienen que funcionar como una misma lógica.

Una conexión técnicamente perfecta sirve de poco si no puede determinar con claridad qué actor tiene derecho a utilizar qué información.

Del mismo modo, un consentimiento bien diseñado pierde valor si las reglas acordadas no pueden traducirse después en límites reales de acceso.

Por eso Open Finance empieza a pasar de una lógica de “puedo conectar” a una lógica de “puedo operar esta conexión de manera controlada”.

Ese cambio también modifica cómo pensamos la experiencia.

Cuando hablamos de fricción, tendemos a imaginar pantallas adicionales, verificaciones o pasos que podrían eliminarse.

Pero en una experiencia financiera abierta, simplificar no siempre significa reducir controles.

Puede significar hacer que esos controles funcionen por detrás sin obligar al usuario a administrarlos manualmente en cada interacción.

→ Que una autorización pueda entenderse.

→ Que sus límites sean claros.

→ Que el acceso responda a esos límites.

→ Que exista evidencia de lo que ocurrió.

Y que el usuario pueda conservar capacidad de decisión después del primer consentimiento.

La sofisticación está detrás.

La claridad debería estar delante.

Ese equilibrio se vuelve especialmente relevante porque Open Finance promete experiencias cada vez más personalizadas.

La combinación de datos, digitalización e inteligencia artificial permite construir servicios ajustados a necesidades mucho más específicas. Pero esa capacidad convive con una tensión evidente: los usuarios quieren mejores experiencias sin perder privacidad ni control sobre decisiones que afectan su vida financiera.

No es una contradicción.

Es probablemente el estándar que la siguiente etapa de Open Finance tendrá que resolver.

Queremos experiencias que sepan más de nosotros cuando ese conocimiento aporta valor.

Pero queremos también entender qué información están utilizando y para qué.

Queremos evitar repetir datos que ya entregamos.

Pero no queremos que esa información circule sin límites.

Queremos personalización.

No necesariamente exposición.

Por eso conectar más datos no es, por sí solo, una señal de madurez.

En algunos casos, incluso puede aumentar la complejidad.

Más actores significa más relaciones.

Más relaciones significan más permisos.

Y más permisos exigen una forma más clara de administrarlos.

La infraestructura empieza entonces a tener una función menos visible, pero más importante: absorber esa complejidad para que el usuario no tenga que hacerlo.

Ese puede ser uno de los cambios más relevantes en cómo entendemos Open Finance.

La primera etapa estaba muy centrada en posibilitar el intercambio.

La siguiente tiene que conseguir que ese intercambio sea utilizable.

Que una conexión no dependa únicamente de que dos sistemas puedan hablar entre ellos, sino de que sepan bajo qué reglas pueden hacerlo.

Que los permisos no sean una formalidad previa al acceso, sino una parte activa de la operación.

Que la seguridad no aparezca solo como una barrera al inicio, sino como una condición continua.

Y que abrir datos no implique perder de vista qué ocurre con ellos después.

Desde fuera, probablemente todo esto debería sentirse bastante simple.

Una persona autoriza un servicio.

La información necesaria llega donde tiene que llegar.

La experiencia funciona.

Pero esa simplicidad visible depende de una arquitectura bastante más exigente detrás.

Y ahí está la paradoja.

Cuanto más fácil queremos que se sienta Open Finance para el usuario, más capacidad necesitamos para gestionar la complejidad que él no ve.

La conexión es solo una parte.

También hay que gestionar quién entra, qué puede hacer, qué información puede utilizar y hasta cuándo.

Eso es lo que convierte una API abierta en una experiencia realmente utilizable.

Y también lo que permite que Open Finance avance sin pedirle al usuario que confíe a ciegas.

La confianza puede apoyarse en algo mucho más concreto:

control que funciona.

Porque abrir datos crea posibilidades.

Pero conseguir que esa apertura pueda operar con claridad, seguridad y límites es lo que convierte esas posibilidades en una experiencia.