Qué es una API y por qué es importante para la tesorería

Cuando en una reunión de tesorería alguien dice "esto se puede hacer por API", casi siempre llegan las mismas preguntas: ¿cuál es el layout?, ¿cómo se va a enviar la información?, ¿el layout es igual al que ya tenemos? Son preguntas razonables. Quien lleva años operando con archivos y host to host piensa en archivos, porque así ha funcionado su tesorería, y funciona bien.

Este explicador es para esa persona. Mi tesis es sencilla: una API no es una tecnología exótica ni un sustituto del archivo; es otra forma de pedirle algo al banco, una operación a la vez, con respuesta inmediata. Entender esa diferencia basta para saber cuándo conviene y por qué las finanzas digitales se están construyendo sobre APIs.

Qué es una API, sin tecnicismos

API son las siglas en inglés de interfaz de programación de aplicaciones. El nombre asusta más que la idea. La forma más simple que conozco de explicarla es esta: una API es un pedazo de código en tu sistema que llama a un servicio de otro sistema y recibe una respuesta.

Tu ERP no "entra" al banco ni se conecta a su base de datos. Le hace una pregunta o una petición con un formato acordado, por un canal seguro, y el banco contesta. Por ejemplo:

• Pregunta: "¿Cuál es el saldo de esta cuenta ahora?". Respuesta: el saldo, en un segundo.
• Petición: "Envía esta transferencia por 250,000 pesos a esta CLABE". Respuesta: "Recibida, este es su número de rastreo".
• Pregunta: "¿Qué pasó con el pago de ayer?". Respuesta: "Liquidado a las 10:42".

Cada pregunta con su respuesta se llama llamada. A "usar" una API se le dice consumirla. Y el sistema que la usa (tu ERP, tu TMS o una aplicación) es el consumidor. Con esas tres palabras ya se puede seguir cualquier conversación con el área de sistemas.

¿Y el layout? Sigue existiendo, solo cambia de forma

Aquí está la confusión más común, y conviene resolverla de frente. En el mundo de archivos, el layout dice qué campos lleva cada renglón, en qué orden y con qué longitud. Cada banco tiene el suyo, y por eso la pregunta "¿es igual al que tengo?" tiene sentido.

En una API también hay reglas sobre qué datos se mandan y cómo. Solo que no se llaman layout, sino especificación o contrato de la API: un documento que dice qué campos lleva cada petición (cuenta de origen, CLABE de destino, monto, referencia), cuáles son obligatorios y qué contesta el banco en cada caso. En lugar de un renglón de longitud fija, cada operación viaja como un mensaje con nombre en cada campo, casi siempre en un formato llamado JSON.

{
  "cuenta_origen": "0123456789",
  "clabe_destino": "012180001234567891",
  "monto": 250000.00,
  "referencia": "FAC-10458"
}

Ejemplo ilustrativo, no corresponde a la especificación de ningún banco.

Entonces, la respuesta honesta a "¿es igual al que tengo?" es: no, pero los datos de fondo son los mismos. Si hoy tu archivo lleva cuenta, beneficiario, monto y referencia, la API pedirá lo mismo con otro empaque. El trabajo de mapear tus datos a ese empaque lo hace quien integra, no el tesorero.

Cuatro formas de hablar con el banco

Una tesorería puede conectarse con su banco de cuatro maneras. No se excluyen: muchas empresas usan varias a la vez.

La diferencia de fondo no es la tecnología, es el ritmo. El archivo y el host to host trabajan por lotes: juntan, mandan y esperan. La API trabaja por evento: pregunta y obtiene la respuesta.

Lo que gana la tesorería

Para quien no quiere hablar de tecnología, conviene hablar del servicio. Lo que una API permite hacer, en términos de tesorería, es esto:

1. Saldo y movimientos al momento. No esperar al estado de cuenta del día siguiente para saber cuánto hay y qué entró.
2. Estatus de cada pago. Saber si un pago se liquidó, se rechazó o sigue en proceso, sin llamar al banco.
3. Avisos automáticos de cobro. El banco avisa al sistema en cuanto entra un depósito (a eso se le llama webhook o notificación), y la cobranza puede aplicarse sola si el pago trae una buena referencia. El webhook tiene su propio explicador.
4. Pagos dentro del flujo del negocio. Un reembolso, un pago a un proveedor urgente o una dispersión que sale desde el sistema que la origina, sin pasar por un archivo.
5. La base para la automatización y la IA. Es tan importante que merece su propia sección.

Lo que necesita un agente de IA para operar una tesorería

Se habla mucho de agentes de inteligencia artificial y de skills que podrán apoyar a la tesorería. Mi tesis es que, antes de cualquier modelo, un agente necesita dos cosas: primero, datos confiables; segundo, servicios apificados que pueda consumir.

• Datos confiables. Si el saldo llega tarde, si el depósito no trae referencia o si el catálogo de proveedores tiene cuentas viejas, el agente va a razonar sobre información equivocada, y lo hará rápido. La IA no corrige un dato malo: lo multiplica.
• Servicios apificados. Un agente no puede entrar al portal del banco ni esperar el archivo de mañana. Para consultar un saldo, revisar el estatus de un pago o preparar una transferencia necesita una API que le conteste, con los permisos y las aprobaciones que la empresa defina. Sin API, el agente solo puede opinar; con API, puede operar bajo control.

Hay otras piezas, como los conectores que traducen esas APIs a algo que el agente entiende, y les dedicaré un artículo aparte. Pero sin estas dos, todo lo demás se queda en demostración. Es la continuación práctica de lo que escribí sobre la tesorería agéntica.

Por qué el futuro de las finanzas digitales pasa por APIs

Casi todo lo nuevo en pagos y tesorería supone que los sistemas pueden hablar entre sí en tiempo real: cobros que se concilian solos, pagos instantáneos, plataformas que integran el pago dentro de su propio servicio, asistentes de IA que consultan información financiera. Ninguna de esas piezas funciona esperando un archivo al día siguiente. Por eso digo que las finanzas digitales, y con ellas la tesorería corporativa, se están apificando.

En México, la regulación también empujó en esa dirección: la Ley para Regular las Instituciones de Tecnología Financiera (Ley Fintech, 2018) obliga a las entidades financieras a compartir ciertos datos mediante interfaces estandarizadas, y la CNBV ha emitido los estándares para hacerlo. Conviene distinguir: esas APIs de finanzas abiertas sirven para que terceros autorizados consulten datos; las APIs para operar la tesorería (pagar, cobrar, consultar saldos propios) son un servicio que cada banco decide ofrecer.

Eso no significa que el archivo vaya a desaparecer. Para una nómina de miles de empleados o un lote semanal de proveedores, el host to host sigue siendo una solución eficiente y probada. Mi lectura es que la tesorería que viene será híbrida: lotes por archivo donde el volumen lo justifica, y API donde importa el tiempo real.

¿Qué tan difícil es integrar una API?

Depende menos de la API y más de la empresa. Estas son las piezas que siempre aparecen:

• Alguien que programe o configure. El tesorero no escribe código, pero alguien sí: el área de sistemas, el proveedor del ERP o un integrador.
• Credenciales y seguridad. La empresa recibe llaves o certificados para identificarse ante el banco, y tiene que guardarlos y renovarlos.
• Ambiente de pruebas. Los bancos que ofrecen APIs suelen dar un sandbox, un espacio para probar con datos ficticios antes de mover dinero real.
• Reglas de autorización. Quién puede mandar qué, hasta qué monto y con qué aprobaciones. La API no elimina la mancomunada; la traslada al sistema.
• Mantenimiento. Las APIs cambian de versión. Alguien tiene que estar al pendiente.

Una consulta de saldo puede quedar lista mucho antes que un flujo completo de pagos con aprobaciones. Por eso suele convenir empezar por consultas, que no mueven dinero, y después pasar a pagos.

¿Dónde se pone la API: en mi tienda en línea, mi ERP, mi TMS o mi sistema de cobranza?

Es de las primeras dudas, y la respuesta es que la API no se instala en un solo lugar. Se conecta en cada sistema que necesita algo del banco, justo donde nace o donde se usa ese dato. Del lado del banco hay un catálogo de servicios; del lado de la empresa, cada sistema toma los que le sirven.

No hace falta conectarlos todos al mismo tiempo. Lo práctico es empezar por el sistema donde hoy duele más: si tu equipo pasa horas identificando depósitos, empieza por cobranza; si la dirección pide la posición de caja cada mañana y nadie la tiene a tiempo, por el TMS. Cada sistema se conecta con sus propias credenciales y permisos, y la tienda en línea, por ejemplo, no tiene por qué poder pagar a proveedores.

Cuando son varios sistemas, muchas empresas ponen en medio una sola capa de integración, a veces el mismo TMS, que habla con el banco y reparte a cada sistema lo que le toca. Ese es justo el segundo de los tres caminos que siguen.

¿Y con mi ERP?

Hay tres caminos, del más sencillo al más laborioso:

1. Conector que ya existe. Algunos ERP y sistemas de tesorería (TMS) traen conectores con ciertos bancos. Si el tuyo lo tiene, el trabajo es sobre todo de configuración.
2. Un intermediario. Un TMS o una plataforma de conectividad se conecta con varios bancos y el ERP habla solo con ella.
3. Desarrollo a la medida. El área de sistemas o un integrador programa la conexión directa con la API del banco. Es lo más flexible y lo que más trabajo exige.

La pregunta útil no es "¿se puede?", porque casi siempre se puede, sino cuánto desarrollo exige y quién lo va a mantener.

Tres preguntas para hacerle a tu banco

1. ¿Qué operaciones ofrecen por API (saldos, movimientos, pagos, estatus, avisos de cobro) y dónde está la documentación?
2. ¿Tienen ambiente de pruebas y quién nos acompaña en la integración?
3. ¿Hay un conector con nuestro ERP o TMS, o la conexión es a la medida?