Cómo transformar tu tesorería sin esperar la API bancaria perfecta

Llevo 12 meses metido dentro de los procesos de tesorería de players de la industria de inversiones (administradoras de fondos, corredoras de bolsa , sociedades de inversión). Viendo cómo un equipo de tesorería abre el día, cuadra saldos, dispersa pagos y concilia contra el banco. Y hay algo que se repite en prácticamente todos los casos, sin importar el tamaño de la institución ni cuán sofisticada sea su operación de inversión: la tecnología con la que opera la tesorería no depende de la madurez tecnológica de la empresa. Depende de la madurez de cada banco con el que trabaja (y esa madurez no es homogénea).

Ninguna tesorería de la industria se va a cambiar de banco por una API. La relación bancaria de una institución regulada no se decide por tecnología: hay historia de crédito, líneas, condiciones comerciales, años de relación construida.

Lo que sí cambia es la pregunta que viene después de aceptar esa restricción, ¿cómo transformo mi tesorería con los bancos que ya tengo, sin esperar a que todos alcancen el mismo nivel de madurez tecnológica al mismo tiempo?.

La condición de partida

En la práctica, una misma tesorería convive, el mismo día, con un banco que ofrece API en tiempo real, otro con conexión Host-to-Host de los 2000, y un tercero donde se opera todavía por portal web con token físico. Lo anterior refleja que cada banco avanza su tecnología al ritmo de su propia estrategia comercial.

La heterogeneidad bancaria es estructural. No se resuelve migrando de banco, y tampoco tiene sentido esperar a que los siete bancos con los que trabaja una empresa de inversiones lleguen al mismo nivel de madurez al mismo tiempo. Diseñar la tesorería asumiendo esa heterogeneidad como dato de entrada es el punto de partida.

¿Cómo se puede convivir con tanta diferencia de madurez tecnológica?

El dolor real está en el equipo humano que tiene que operar como capa de traducción entre tres, cuatro, cinco niveles de madurez distintos, todos los días, sin que eso figure en ningún organigrama.

He visto el mismo patrón una y otra vez:

• Inicio del día distinto según banco. Para uno, un webhook (una notificación que el banco dispara automáticamente en el instante en que algo ocurre, sin que nadie tenga que ir a buscarla) confirma en segundos que un pago se liquidó. Para otro, alguien tiene que entrar al portal, descargar la cartola y marcar manualmente que se liquidó.
• Conciliación con reglas propias por banco. No hay un único proceso de conciliación sino que hay tantos procesos como bancos, y el conocimiento de cómo hacerlo vive en la cabeza de una o dos personas del equipo.
• Escalamiento que penaliza el crecimiento. Cada fondo nuevo, cada RUT nuevo, no se suma linealmente a la carga operativa, al contrario, la multiplica, porque replica el mismo problema de traducción manual en una nueva instancia.

Lo anterior es la consecuencia lógica de no tener una capa que absorba la diferencia. El equipo de tesorería termina haciendo, todos los días, el trabajo que debería hacer una integración.

La imagen anterior retrata la diferencia de madurez tecnológica, y no es que un banco sea mejor que otro, sino que cada banco entrega tecnología distinta según su propuesta de valor.

Hoy, en Shinkansen contamos con un benchmark que muestra las capacidades de cada banco para Chile y Perú, si lo quieres, ¡envíame un correo!

Por qué no hay dos tesorerías iguales

Esta diferencia de madurez tecnológica es la razón de por qué nunca llegamos a un cliente con una respuesta pre-armada. Cada institución tiene una combinación distinta de bancos, cada banco está en un punto distinto de esa curva de madurez, y cada equipo de tesorería desarrolló, con los años, sus propios rituales para sostener esa combinación específica.

Dentro de estos rituales hemos visto: grupos de WhatsApp con apoderados, cajones de escritorios con tokens clasificados por cuenta y banco, scrappers que intentan replicar el comportamiento de apoderados (y que se caen constantemente, rompiendo la continuidad operacional), horarios especiales de almuerzo para los apoderados para que estén disponibles a la hora de los pagos (que se concentran generalmente entre 12:00-14:00 hrs), entre muchos otros.

Como ven, no existe un "problema genérico de conectividad bancaria" sino que existe la manera particular en que esa asimetría se resuelve (o no se resuelve) en cada operación.

Como no hay dos tesorerías iguales, no hay dos soluciones iguales. Por eso en Shinkansen hemos aprendido que la mejor forma de transformar la tesorería de una empresa de inversiones es realizar primero un “deep dive” a la operación actual. Adentrarse en la operación de tesorería, reunirse con equipos de ciberseguridad, fiscalía, riesgos, tecnología, operaciones y finanzas. Mapear cada proceso con cada banco. A ese “deep dive” le pusimos nombre en Shinkansen: discovery.

Esto lo aprendí antes de estar en Shinkansen. Pasé tres años en consultoría estratégica dentro de operaciones de clientes, articulando a los distintos stakeholders de un proceso (el equipo que lo ejecuta, el gerente que lo supervisa, el directorio que lo audita) hasta construir una vista que ninguno de ellos tenía completa por separado. Es el mismo ejercicio de mapear un proceso operativo hasta el nivel de detalle donde deja de ser opinión y se vuelve evidencia (con el rigor de entregable para C-level que un equipo interno rara vez tiene tiempo, o distancia, para construir sobre sí mismo).

Esa distancia importa más de lo que parece. El equipo que opera la tesorería todos los días generalmente dejó de ver lo que a un tercero le salta a la vista: el paso manual que nadie cuestiona porque "siempre se hizo así", el conocimiento crítico que vive en la cabeza de una sola persona, la razón real (no la oficial) por la que un proceso toma el doble de tiempo en un banco que en otro. Ese es el punto ciego que un discovery externo, bien ejecutado, existe para resolver.

Por eso el primer paso siempre es un discovery de cuatro semanas metidos dentro de la operación real. Mapeamos banco por banco qué nivel de madurez tiene la conexión, qué procesos manuales existen para compensar esa diferencia, dónde está el conocimiento crítico concentrado, y qué parte de la carga operativa crece linealmente con cada fondo o entidad nueva y cuál se multiplica. Al cierre de esas cuatro semanas, el resultado es una hoja de ruta construida sobre las particularidades exactas de esa tesorería: qué se automatiza primero, en qué orden, y qué gana el equipo en cada etapa.

Esa disciplina (entender antes de vender) es la que permite que la transformación no sea un proyecto de tecnología genérico, sino una intervención calibrada a cómo esa institución específica convive, hoy, con la asimetría bancaria.

Y esa capa no queda fija en el tiempo. Cuando alguno de los bancos con los que ya trabaja el cliente lanza una API nueva, mejora un canal o levanta una limitación, esa mejora se incorpora una sola vez a la integración y queda disponible de inmediato para toda la base conectada a ese banco, esa es la propuesta de valor de Shinkansen. La tesorería no necesita un proyecto propio para capturar el avance de su banco: lo recibe en semanas, sin pedírselo a nadie.

La pregunta que sí vale la pena hacerse

Después de este año, la pregunta que me parece más útil no es "¿qué banco es mejor para mi operación?". Esa pregunta ya no es completamente del Gerente de Operaciones o del CFO de responder, depende de decisiones comerciales y de crédito que están fuera del control de tesorería.

La pregunta que sí vale la pena hacerse es otra: “¿quién se convierte en el nivelador de la asimetría (el traductor entre bancos) para que la tesorería deje de operar al ritmo del banco más lento y empiece a operar al ritmo que el negocio necesita hoy?”

Esto importa más de lo que parece. La conversación sobre agentes de IA en tesorería (flujos que se ejecutan solos, anomalías que se detectan antes de ocurrir, conciliación sin intervención humana) asume una condición previa: que existe una capa homogénea sobre la cual esos agentes pueden operar. Un agente no automatiza lo que hoy resuelve una persona interpretando de memoria las particularidades de cada banco. Primero hay que nivelar la asimetría. Recién después, automatizar sobre ella.

Esa es, en el fondo, la pregunta de arquitectura que define si una tesorería está lista para el salto que ya está ocurriendo en la industria o si cada línea de crecimiento (un fondo nuevo, un país nuevo, un banco nuevo) sigue pagándose con más carga operativa, más riesgo de error humano, y una brecha creciente respecto de lo que la tecnología ya permite hacer.

La madurez bancaria asimétrica no se va a resolver con todos los bancos migrando al mismo ritmo. Eso no va a pasar. La pregunta que sí tiene respuesta es quién se para en el medio a nivelarla y si esa función sigue dependiendo de personas, o ya es infraestructura. En Shinkansen construimos esa infraestructura.