De la fragmentación a la línea de fractura: el estándar de API ausente de la banca corporativa en la era agéntica

La banca minorista tuvo su estándar de API hace una década. La banca corporativa nunca lo tuvo — y en 2026 esa omisión ha dejado de ser una molestia para volverse una línea de fractura. ISO 20022 dio al sector una gramática común; nunca le dio una superficie común, lista para agentes. Ahora quien llama ha cambiado. Ya no es un desarrollador con un trimestre por quemar en integración, sino un modelo que descubre herramientas en tiempo de ejecución y mueve dinero dentro de bandas de política. La ambigüedad que los tesoreros corporativos han absorbido en silencio durante veinte años está a punto de entregarse a software que no puede absorberla — mientras la capa de datos que hay debajo se estructura a la fuerza, guste o no a los bancos. Esto es lo que cuesta la dirección ausente, por qué los agentes hacen que la fragmentación actual sea insegura en lugar de meramente ineficiente, y qué debe exigir un estándar de API de banca corporativa antes de que la tesorería autónoma pueda escalar.

Resumen ejecutivo

La banca corporativa tiene la gramática, no la superficie. ISO 20022 estandarizó los datos; nadie estandarizó la API. Eso era soportable mientras un integrador humano absorbía la ambigüedad — un modelo en tiempo de ejecución no puede.

Quien llama ha cambiado. MCP convirtió el descubrimiento de herramientas en una decisión en tiempo de ejecución. Un agente concebido para abolir el problema de integración M×N vuelve a encontrárselo en la frontera del banco, donde cada institución es un servidor a medida con su propia semántica.

La fragmentación ahora mueve dinero de forma incorrecta, a velocidad de máquina. Un tiempo de espera agotado, tres bancos, tres verdades contradictorias — un duplicado en A, una instrucción atascada en B, un fallo silencioso en C. La idempotencia y una gramática de errores determinista pasan a ser estructurales.

Envolver cada banco en un servidor MCP reubica el pantano. Cuarenta servidores, cuarenta semánticas, ningún piso no funcional compartido — y un modelo no determinista con acceso de escritura a los raíles de pago, de lleno un problema de SR 11-7 / DORA / EU AI Act.

Estandarice su propia superficie, o conviértase en la mercancía. Los bancos que publiquen ahora una API nativa de ISO 20022 y lista para agentes se convierten en las contrapartes por defecto de la tesorería autónoma; los demás alquilan su relación con el cliente a quien sea dueño del adaptador.

Dos mundos bancarios, uno de ellos estandarizado

Mire la banca minorista y el cuadro es desordenado pero navegable. Europa tiene el UK Open Banking y el NextGenPSD2 del Berlin Group, este último adoptado por más de tres cuartas partes de los bancos europeos y tratado en la práctica como un estándar de facto. Estados Unidos tiene el Financial Data Exchange, que ya abarca más de sesenta millones de cuentas de consumidores. Australia tiene el Consumer Data Right. Ninguno de estos es global, y ninguno es probable que llegue a serlo — pero cada uno es un contrato real, versionado y comprobable por máquina, y allí donde los contratos se agotan, los agregadores (Plaid, Tink, TrueLayer, Salt Edge) absorben la diferencia detrás de una única interfaz. La fragmentación minorista es un impuesto. No es un muro.

La banca corporativa y mayorista no tiene equivalente. Una tesorería multinacional llega a sus bancos mediante tuberías de archivos host-to-host, una docena de portales a medida, un sistema de gestión de tesorería o un agregador — normalmente los cuatro a la vez. Esto no es un hombre de paja: la propia investigación de McKinsey sobre banca transaccional ha catalogado el mismo legado durante años, describiendo cómo los bancos se apoyan en la transferencia de archivos host-to-host y SFTP, enumerando los modos de fallo bien conocidos de la integración basada en archivos — formatos ERP voluminosos que deben personalizarse para cada empresa, una incapacidad para gestionar el enrutamiento condicional — e informando de que más del 85 % de los directivos de banca transaccional tienen intención de invertir en API de gestión de efectivo. El apetito por las API no está en duda. Lo que falta es el contrato común al que apuntan.

Porque los candidatos habituales no lo son. A ISO 20022 se le confunde con frecuencia con el estándar ausente, pero es una gramática de datos, no un contrato de API: pain.001 le dice cómo formular una transferencia de crédito, no qué endpoint la crea, cómo se autentica, cómo pagina o cómo le comunica que ha fallado. BIAN da al sector un modelo de referencia semántica compartido, no una interfaz impuesta. Las API de Payment Initiation e Instant Cash Reporting de Swift son un avance genuino hacia la estandarización, pero son céntricas en la red y aún emergentes, no una superficie universal. El marco openFinance del Berlin Group se acerca a casos de uso corporativos — apertura de cuentas, financiación del comercio, pagos recurrentes dinámicos — pero es europeo, temprano y premium por acuerdo. Reúna todo eso y todavía no tiene un estándar de API de banca corporativa vinculante y global. Tiene materiales de construcción y ningún plano.

Por qué sobrevivió la fragmentación — y por qué eso se está acabando

Durante veinte años esto fue tolerable, porque el integrador era humano y paciente. Una empresa incorporaba un puñado de conexiones bancarias a lo largo de meses, a veces trimestres. Cada una era un proyecto: certificados intercambiados, una prueba de céntimo ejecutada, un documento de mapeo discutido. El coste era real pero se pagaba una vez por relación y se amortizaba a lo largo de años de pagos posteriores. Cuando la API de un banco estaba infraespecificada — cuando un estándar «dejaba el resto a la institución que lo implementa», como los propios bancos se quejan de que hace — un ingeniero humano leía el portal, inferría la intención y tapaba la brecha. La ambigüedad era soportable porque había una persona ahí para resolverla.

También sobrevivió por razones que se dicen en voz alta con menos frecuencia. La fontanería subyacente es genuinamente difícil de cambiar: ventanas de liquidación por lotes, ciclos nocturnos y núcleos de mainframe que nunca se diseñaron para responder a una pregunta en tiempo real. Y la fragmentación no es solo un accidente — es, en silencio, una forma de dependencia. Cada tubería host-to-host a medida que construye un tesorero es un coste de cambio que se acumula en favor del titular. Un banco difícil de integrar es, al margen, un banco difícil de abandonar. Nada de esto es conspirativo; es incentivo corriente. Pero explica por qué un sector que ha acordado una gramática de datos nunca ha acordado una superficie — y por qué la superficie es la última capa sin estandarizar que queda. La razón por la que ya no puede sostenerse es que la capa que hay debajo se está estructurando a la fuerza contra una fecha límite, y la capa que hay encima acaba de adquirir un usuario nuevo e impaciente.

Quien llama ha cambiado

Ese usuario llegó en dieciocho meses. El Model Context Protocol, que Anthropic liberó como código abierto en noviembre de 2024 y donó a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025 junto a Block y OpenAI, se ha convertido en la forma por defecto en que los sistemas de IA acceden a herramientas y datos. A principios de 2026 registraba unos noventa y siete millones de descargas de SDK al mes; a mediados de año, según una lectura direccional del sector, alrededor del setenta y ocho por ciento de los equipos de IA empresariales ejecutaban agentes respaldados por MCP en producción y más de una cuarta parte de las Fortune 500 operaban servidores MCP, asegurados mediante una capa de autorización estándar OAuth 2.1. Se describe habitual y acertadamente como el USB-C de la IA: colapsa la pesadilla de integración M×N — cada modelo cableado a mano a cada herramienta — en M+N. Su propio resumen de sí mismo es la frase que importa para los bancos: las API son para programas; MCP es para agentes. Una API REST espera que quien llama sepa de antemano qué endpoint invocar y con qué parámetros. Un agente espera descubrir las herramientas disponibles en tiempo de ejecución y decidir, por sí mismo, cómo y cuándo usarlas.

Esto no es hipotético para la tesorería. El patrón ya es consistente en las tesorerías de banca corporativa y de inversión en 2026: un agente lee datos de efectivo ISO 20022, invoca un conjunto acotado de herramientas y reequilibra la liquidez dentro de bandas de política, con controles de SR 11-7, DORA y EU AI Act envueltos a su alrededor. La gramática de datos está lista para eso. La superficie de API no lo está.

El desajuste, con precisión

Reduzca el agente a lo que realmente necesita de una contraparte bancaria y la lista es corta e implacable:

Un contrato descubrible por máquina — una descripción OpenAPI, o un manifiesto de herramientas, que el agente pueda leer en tiempo de ejecución en lugar de un PDF que un humano lee una vez.
Un único modelo de autenticación — un perfil OAuth2/mTLS de grado financiero (FAPI es el ancla obvia), no un apretón de manos distinto por banco.
La idempotencia como garantía — una referencia de instrucción única que convierte un pago reintentado en una operación sin efecto, porque un agente reintentará.
Una gramática de errores determinista — que el mismo fallo signifique lo mismo en todas partes, para que el modelo pueda razonar sobre él.
Versionado semántico y descubrimiento de capacidades — para que un agente pueda saber qué puede hacer una contraparte este trimestre sin una nota de lanzamiento humana.
Cargas útiles ISO 20022 estructuradas, consentimiento y permisos, y un rastro de auditoría a prueba de manipulaciones — la sustancia, el permiso y la evidencia.

Coteje eso con la banca corporativa tal como existe y cada línea se fractura en N dialectos — uno por banco. El agente que se suponía que aboliría el problema M×N vuelve a encontrárselo en la frontera del banco, porque cada institución es, en efecto, un servidor a medida con su propia gramática para «saldo», su propia noción de «estado del pago», su propio baile de autenticación y su propia idea de qué es un error. El protocolo estandarizó el lado del agente del cable. Nadie estandarizó el del banco.

Un modo de fallo, hecho concreto

Hágalo específico, porque aquí es donde la abstracción muerde. Imagine un agente de liquidez autorizado a barrer efectivo entre tres bancos para mantener cada cuenta dentro de una banda objetivo. Dispara tres instrucciones casi idénticas y, como suelen hacer las redes, se topa con un tiempo de espera agotado en cada una.

El Banco A trata el tiempo de espera agotado como desconocido — seguro reintentar, así que el agente reintenta, y la instrucción original también se liquida: un pago duplicado. El Banco B trata el mismo tiempo de espera agotado como enviado — no reintentar, pero nunca expone una confirmación que el agente pueda interpretar, así que la instrucción queda en el limbo mientras el agente, al no ver ningún éxito, escala o redirige: un pago atascado y una posición contabilizada por partida doble. El Banco C devuelve un alegre HTTP 200 con un rechazo enterrado en el cuerpo de la carga útil; el agente lee el código de estado, marca el barrido como hecho y sigue adelante: un fallo silencioso que solo aflora a la mañana siguiente como una descuadre de conciliación que nadie puede explicar.

Tres bancos, una condición, tres verdades contradictorias — fondos duplicados saliendo por la puerta en A, una instrucción congelada en B, un éxito fantasma en C. Un tesorero humano habría telefoneado a tres gestores de relación y lo habría resuelto antes del almuerzo. El agente no puede telefonear a nadie. Por esto exactamente «la idempotencia como garantía» y «una gramática de errores determinista» no son detalles arquitectónicos: sin ellos, la misma fragmentación que meramente costaba horas humanas ahora mueve dinero real de forma incorrecta, a velocidad de máquina, a través de todas las contrapartes a la vez.

Por qué «envolver cada banco en un servidor MCP» no es la solución

La respuesta refleja es dar a cada banco un servidor MCP y asunto zanjado. No se sostiene, porque reubica la fragmentación en lugar de eliminarla. Cuarenta bancos se convierten en cuarenta servidores con cuarenta semánticas, cuarenta flujos de autenticación y ningún significado compartido — y, críticamente, ningún piso no funcional compartido: ningún presupuesto de latencia común, ningún nivel de disponibilidad acordado, ninguna garantía de idempotencia comparable. El modo de fallo anterior sobrevive intacto al envoltorio. Peor aún, quien llama es ahora un modelo no determinista con acceso de escritura a los raíles de pago, lo que no es meramente una cuestión de integración sino una de riesgo de modelo y de resiliencia operativa que aterriza de lleno en SR 11-7, DORA y el EU AI Act. Las primitivas de intervención humana de MCP — la elicitación para confirmación, el sampling para razonamiento — son necesarias y bienvenidas, pero un diálogo de confirmación no sustituye a una contraparte que se comporta de forma predecible. No se puede gobernar a escala lo que no se puede describir de manera uniforme. Mil servidores a medida no son un estándar; son el mismo pantano con un barniz de JSON-RPC.

Dos futuros, y una elección estratégica

Quién resuelve esto determina quién posee la relación corporativa durante la próxima década, y solo hay dos candidatos.

En el primero, los bancos estandarizan sus propias superficies. Publican API listas para agentes, mantienen la conexión directa con el tesorero y siguen siendo la contraparte que el agente descubre e invoca. En el segundo, los agregadores lo estandarizan por ellos. Un puñado de plataformas define el contrato de agente de facto, y los bancos se convierten en endpoints intercambiables detrás de él — alcanzables solo a través de la abstracción de otro. Esto no es especulación; es la historia minorista avanzando un segmento. El propio trabajo de McKinsey de 2025 sobre banca transaccional describe cómo plataformas de gestión de tesorería como Kyriba y GTreasury, y plataformas de la oficina del CFO como Bill.com, se posicionan entre clientes y bancos con una visión de posición única y agnóstica al banco. Es precisamente la capa que, en la banca minorista, hizo desaparecer en silencio la larga cola detrás de Plaid y Tink. La misma investigación señala que los tesoreros corporativos ahora exigen a sus bancos los estándares de sus aplicaciones de consumo, y cambiarán cuando la incorporación, los permisos y la integración de API decepcionen.

El contenido estratégico de la elección es rotundo. Un banco que se convierte en un endpoint detrás del contrato de agente de un agregador entrega tres cosas a la vez. Margen, a medida que sus servicios se convierten en mercancía y se comparan primero por precio a través de la interfaz de otro. Propiedad del cliente, a medida que la relación, el contexto y el coste de cambio migran a la plataforma. Y poder de datos y análisis, a medida que el flujo que antes veía de extremo a extremo queda mediado por un intermediario que ve más del cliente que el propio banco. Estandarizar su propia superficie no es un proyecto de higiene técnica. Es la diferencia entre ser la contraparte y ser la mercancía.

Qué debe exigir el estándar

La dirección que falta no es exótica. Cada componente ya existe en abierto — ISO 20022 para los datos, las API de Payment Initiation e Instant Cash Reporting de Swift para operaciones de referencia, BIAN para la semántica, el openFinance del Berlin Group para el patrón de consentimiento y catálogo, FAPI para la autenticación de grado financiero, MCP para la exposición de herramientas, A2A para la orquestación de agente a agente. Lo que está ausente es el acto de ensamblarlos en un contrato vinculante para el espacio corporativo — y la disciplina de especificar dos pisos, no uno. La literatura existente sobre API B2B, la de McKinsey incluida, trata las API en gran medida como una oportunidad de crecimiento y de experiencia. Dice poco sobre determinismo, descubrimiento de capacidades en tiempo de ejecución o no funcionales estandarizados — exactamente la omisión que los agentes no pueden tolerar. Así que el estándar debe ser explícito tanto sobre qué es la interfaz como sobre cómo se comporta bajo gobernanza.

El piso técnico

Un contrato OpenAPI-first con un manifiesto de herramientas MCP canónico generado a partir de él — no escrito a mano junto a él, de modo que las herramientas que ve un agente nunca puedan desviarse de la API que el banco ejecuta.
Autenticación y consentimiento de grado FAPI como único apretón de manos en toda la superficie.
Idempotencia y una taxonomía de errores determinista — códigos estables, un significado por fallo, documentados en el propio contrato.
Cargas útiles nativas de ISO 20022, estructuradas y listas para direcciones híbridas.
Versionado semántico con descubrimiento de capacidades en tiempo de ejecución — un agente puede preguntar qué puede hacer hoy esta contraparte, y obtener una respuesta de máquina.

El piso de gobernanza y resiliencia

SLO no funcionales publicados y exigidos — latencia, disponibilidad, rendimiento, procesamiento directo (STP) y esfuerzo humano — expresados como cifras reales de tiempos y movimientos, no como lenguaje de marketing.
Permisos, consentimiento y un rastro de auditoría a prueba de manipulaciones vinculados a la ruta de ejecución, no flotando en un portal fuera de banda.
Controles de riesgo de modelo y de resiliencia operativa alineados con SR 11-7, DORA y el EU AI Act, de modo que las llamadas de un agente sean eventos gobernados con un responsable, no casos extremos exóticos.

Hay una lección dura enterrada en la experiencia minorista aquí. Un estándar que ejecuta una máquina tiene que ser más preciso que uno que un integrador humano pueda reparar en silencio; la infraespecificación ya no es un coste blando pagado en horas de desarrollador sino un modo de fallo duro pagado en pagos mal enviados. Es revelador que el esfuerzo de armonización más autorizado del sector — los requisitos de datos ISO 20022 armonizados del CPMI y del PMPG, que se está instando a los sistemas de pago de todo el mundo a adoptar antes de finales de 2027 bajo el programa de pagos transfronterizos del G20, para combatir exactamente esta fragmentación — sea, por su propia descripción, ni una regulación ni un estándar de API. Armoniza los datos. La interfaz sigue sin ser tarea de nadie.

Una imagen objetivo

La construcción es menos abrumadora que el diagnóstico, porque son tres capas, no un programa. Una API de banca corporativa canónica expone pagos e informes de efectivo sobre REST y OpenAPI, con cargas útiles nativas de ISO 20022 y autenticación de grado FAPI — un contrato, una gramática, un apretón de manos. Un puente MCP se sitúa por encima de ella y genera el manifiesto de herramientas orientado al agente directamente a partir de ese contrato OpenAPI, de modo que el descubrimiento, los esquemas y los permisos se derivan de la superficie en lugar de mantenerse en paralelo a ella. Y una capa de política y resiliencia envuelve cada llamada de agente con los controles que hacen segura la autonomía: límites de transacción y de contraparte, segmentación, disparadores de intervención humana (elicitación en acciones de alto riesgo), monitorización de SLO en vivo y un interruptor de emergencia rotundo. No se requieren diagramas para captar el punto — el estándar no es un raíl nuevo, es una disposición disciplinada de raíles que ya existen, con la ruta del agente y la ruta de la gobernanza integradas desde el primer commit en lugar de atornilladas después del incidente.

Qué hacen los bancos creíbles en los próximos 24 meses

Si acepta que quien llama ha cambiado, el trabajo es concreto y se desglosa en cinco vías.

Publique una superficie nativa de ISO 20022 y OpenAPI-first. Tome un corredor de alto valor — normalmente pagos transfronterizos e informes de efectivo — y expóngalo mediante una única definición OpenAPI versionada con cargas útiles ISO 20022, alineada con sus esquemas CBPR+ existentes en lugar de una quinta gramática inventada. Hágala pública para clientes y agentes internos, con un sandbox, y trate los cambios como lanzamientos de producto. El éxito del primer año no es la cobertura total; es demostrar que un corredor puede hacerse direccionable por agentes de extremo a extremo.
Estandarice la autenticación y la idempotencia a lo largo de ella. Adopte un único perfil de grado FAPI como el único apretón de manos, exija claves de idempotencia en cada escritura y convierta «reintentar la misma instrucción» en una garantía documentada en el contrato — transformando «los agentes reintentarán» de un riesgo en una suposición segura.
Defina una gramática de errores determinista y el descubrimiento de capacidades. Dé a cada fallo un código estable y una semántica consistente, añada versionado semántico y exponga un catálogo de capacidades que un agente pueda consultar en tiempo de ejecución, con indicadores explícitos de soporte parcial, obsolescencia y «aún no disponible».
Asocie permisos, consentimiento y auditoría a la misma superficie. Traslade los flujos de consentimiento y aprobación a la ruta de la API, emita un rastro a prueba de manipulaciones para cada instrucción iniciada por un agente — quién, qué, cuándo, bajo qué banda de política — y alinéelo explícitamente con SR 11-7, DORA y el EU AI Act para que la segunda línea pueda darle el visto bueno.
Publique pisos no funcionales, luego ejecute un piloto de agente supervisado. Comprométase con objetivos de latencia, disponibilidad, rendimiento y STP para el corredor e instruméntelos; luego ponga en marcha un agente supervisado de liquidez o de barrido de efectivo que use solo esta superficie, con límites rotundos, puntos de control de intervención humana y auditoría completa, durante seis a doce meses. Esta es la función forzadora que usted mismo controla — demuestra que un agente puede mover dinero de forma segura dentro de bandas de política cuando la superficie es predecible, y le dice rápidamente dónde su estándar sigue siendo aspiración en lugar de hecho.

La función forzadora

El sector acaba de demostrar que puede moverse cuando algo lo fuerza. La transición a direcciones estructuradas de Swift de noviembre de 2026 — tras la cual las direcciones no estructuradas en pagos transfronterizos simplemente se rechazan, sin conversión de contingencia — ha arrastrado a un mercado reticente hacia datos ISO 20022 estructurados en una fecha fija, reforzada por el empuje del CPMI de finales de 2027 hacia requisitos de datos armonizados en todo el programa de pagos del G20. Fíjese en lo que ambos esfuerzos estandarizan: los datos, no la interfaz. La gramática se está forzando limpia. La superficie se ha dejado a la discreción de cada banco — que es precisamente la discreción con la que los agentes no pueden trabajar. Para un agente, eso significa que las cargas útiles por fin serán consistentes mientras el comportamiento tras ellas sigue siendo divergente — una inversión de lo que una máquina realmente necesita, que es comportamiento predecible primero y datos limpios después.

Así que este es el error no forzado que hay que evitar: esperar a que un comité global bendiga un estándar de API de banca corporativa antes de actuar. Los bancos que publiquen ahora una superficie nativa de ISO 20022 y lista para agentes — un contrato OpenAPI, un manifiesto MCP generado a partir de él, autenticación de grado financiero y pisos no funcionales que realmente respaldarán — se convertirán en las contrapartes por defecto de la tesorería autónoma. Sus herramientas serán las que los agentes puedan descubrir, en las que confiar e invocar sin un humano en medio. Los bancos que esperen solo serán alcanzables a través de la abstracción de un agregador, alquilando su propia relación con el cliente a quien sea dueño del adaptador.

Una gramática sin dirección no es un estándar. ISO 20022 le dijo a la banca corporativa cómo hablar. Nunca le dijo adónde ir. Los agentes han llegado, fluidos e impacientes, y el mapa sigue sin estar ahí. Dibujarlo es ahora el trabajo de infraestructura más trascendental de la banca transaccional — y, por una vez, la fecha límite no la fija un regulador sino las máquinas que ya esperan en la interfaz.

Preguntas frecuentes

¿No es ISO 20022 el estándar ausente? No. ISO 20022 es una gramática de datos, no un contrato de API. pain.001 le dice a un sistema cómo formular una transferencia de crédito; no dice qué endpoint la crea, cómo se autentica, cómo pagina o cómo informa de un fallo. La gramática está lista para agentes. La superficie — la interfaz descubrible por máquina y de comportamiento uniforme que un agente realmente invoca — no lo está.

¿Por qué no simplemente envolver cada banco en un servidor MCP? Porque reubica la fragmentación en lugar de eliminarla. Cuarenta bancos se convierten en cuarenta servidores con cuarenta semánticas, cuarenta flujos de autenticación y — críticamente — ningún piso no funcional compartido: ningún presupuesto de latencia común, ningún nivel de disponibilidad acordado, ninguna garantía de idempotencia comparable. Quien llama es ahora un modelo no determinista con acceso de escritura a los raíles de pago, lo que es un problema de riesgo de modelo y de resiliencia operativa bajo SR 11-7, DORA y el EU AI Act. Mil servidores a medida no son un estándar.

¿Cuál es el primer movimiento más útil para un banco? Publicar un corredor nativo de ISO 20022 y OpenAPI-first — normalmente pagos transfronterizos e informes de efectivo — con un apretón de manos de grado FAPI, la idempotencia como garantía documentada y una gramática de errores determinista. Luego ejecutar un piloto de agente supervisado contra solo esa superficie, con límites rotundos, puntos de control de intervención humana y auditoría completa. Demostrar un corredor de extremo a extremo supera a una hoja de ruta que cubre todo y no exige nada.

¿Quién resuelve esto si los bancos no lo hacen? Los agregadores. Un puñado de plataformas de tesorería y de la oficina del CFO definirán el contrato de agente de facto, y los bancos se convertirán en endpoints intercambiables detrás de él — entregando margen, propiedad del cliente y datos de extremo a extremo a la vez. Es la historia minorista, donde Plaid y Tink absorbieron la larga cola, avanzando un segmento hacia la banca corporativa.

Referencias

Model Context Protocol — documentación oficial ⧉. [MCP liberado como código abierto en noviembre de 2024 y donado a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025 junto a Block y OpenAI; la capa de descubrimiento de herramientas en tiempo de ejecución sobre la que se construye el análisis. Las cifras de adopción en el texto son lecturas direccionales del sector y se señalan como tales.]
Berlin Group — NextGenPSD2 y openFinance ⧉. [El estándar de API minorista europeo de facto y su alcance hacia casos de uso corporativos — citado por el patrón de consentimiento y catálogo y el contraste minorista frente a corporativo.]
Financial Data Exchange (FDX) ⧉. [El estándar estadounidense de intercambio de datos minorista, citado por la escala de contratos minoristas estandarizados frente a los que la banca corporativa no tiene equivalente.]
McKinsey & Company — Perspectivas de Servicios Financieros ⧉. [Investigación sobre API de banca transaccional: el legado host-to-host / SFTP, la intención de inversión en API de gestión de efectivo del ~85 % y la intermediación de plataformas de tesorería. Citada por el diagnóstico de mercado; el enfoque y las conclusiones aquí son del propio autor.]
Banco de Pagos Internacionales (CPMI) — Requisitos de datos ISO 20022 armonizados ⧉. [El empuje de finales de 2027 para armonizar los datos de pago — por su propia descripción ni una regulación ni un estándar de API — citado por el punto de «gramática sin superficie».]
Swift — ISO 20022 para instituciones financieras ⧉. [CBPR+ y el hito de la dirección estructurada de noviembre de 2026; las API de Payment Initiation e Instant Cash Reporting citadas como operaciones de referencia, no una superficie universal.]

Última revisión: julio de 2026. Análisis original; las fuentes se citan, no se reproducen. Las cifras de adopción y de mercado son lecturas direccionales del sector — verifíquelas frente a fuentes primarias antes de su republicación. Licenciado bajo CC-BY-4.0.

Última revisión 2026-07-08.

Volver a publicar este artículo

From Fragmentation to Fault Line: Corporate Banking's Missing API Standard in the Agentic Era — Sebastien Rousseau

La banca minorista tuvo su estándar de API hace una década. La banca corporativa nunca lo tuvo — y ahora que los agentes de IA y el Model Context Protocol han convertido la integración en una decisión en tiempo de ejecución, la brecha se ha vuelto una línea de fractura.

Este artículo se publica bajo Creative Commons Attribution 4.0 International. La republicación requiere atribución a la URL canónica.

From Fragmentation to Fault Line: Corporate Banking's Missing API Standard in the Agentic Era — Sebastien Rousseau

La banca minorista tuvo su estándar de API hace una década. La banca corporativa nunca lo tuvo — y ahora que los agentes de IA y el Model Context Protocol han convertido la integración en una decisión en tiempo de ejecución, la brecha se ha vuelto una línea de fractura.

Originally published at https://sebastienrousseau.com/es/2026-07-07-corporate-banking-api-standard-agentic-mcp-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER