Cinco proveedores tocan una sola operación: diseñar producto sin controlar la cadena

Cuando alguien pulsa «enviar» en un producto financiero, cree que está usando una aplicación. En realidad está activando una cadena de entidades independientes que no se conocen entre sí, tienen horarios distintos, criterios de riesgo distintos y ninguna obligación de coordinarse. La empresa que construye la interfaz —la que aparece en la pantalla y recibe el correo cuando algo falla— casi nunca controla esa cadena entera.

Esa es, en mi experiencia, la diferencia real entre construir software y construir infraestructura: no diseñas un producto, diseñas el contrato entre sistemas que nunca se hablaron.

La aritmética que nadie enseña en la demo

Si una operación atraviesa cinco capas y cada una está disponible y responde correctamente el 99,5 % del tiempo, la probabilidad de que las cinco funcionen a la vez no es 99,5 %: es aproximadamente 97,5 %. Traducido, una de cada cuarenta operaciones toca algo. Con volumen, «una de cada cuarenta» deja de ser una nota al pie y se convierte en tu equipo de soporte.

El error de diseño más común es tratar ese 2,5 % como incidencias del backend. No lo son: son parte del producto, y son exactamente la parte que el usuario recordará.

Las cinco capas de una operación

Este es el mapa que utilizo para situar responsabilidades antes de escribir una línea de interfaz. No todas las operaciones atraviesan las cinco, y quién ocupa cada capa cambia según el producto y la jurisdicción; lo que no cambia es que cada capa necesita un responsable identificable.

• Capa 1 Identidad y verificación Quién es el usuario y si puede operar. Suele recaer en un proveedor especializado y en los criterios de la entidad regulada que da servicio.
• Capa 2 Origen y elegibilidad de los fondos De dónde viene el valor y si esa procedencia es aceptable para la siguiente capa. Es la capa que más rechazos silenciosos genera.
• Capa 3 Ejecución y liquidación El movimiento en sí: el riel, sus horarios, sus cortes y sus reintentos. Es la única capa que el sector suele mostrar.
• Capa 4 Resguardo y control de acceso Dónde queda el valor mientras la operación está en curso y quién puede moverlo. Cada modelo —custodia por un tercero regulado o autocustodia por el propio usuario— reparte esta responsabilidad de forma distinta.
• Capa 5 Última milla La entrega efectiva al beneficiario y su visibilidad en el extremo receptor. Es la capa sobre la que menos control tienes y la que define la percepción de éxito.

Tres reglas que aplico

1. Los estados se nombran por dónde está el valor, no por quién lo tiene

«Pendiente en el proveedor B» es una fuga de arquitectura hacia la pantalla del usuario. «Recibido por la entidad del beneficiario, pendiente de abono» describe la misma realidad sin obligar a nadie a conocer tu diagrama interno —y sigue siendo cierto el día que cambies de proveedor.

2. Cada operación tiene un dueño en todo momento

En una cadena de cinco actores, el peligro no es que uno falle: es que la operación se quede sin dueño mientras cada parte espera a la otra. Antes de lanzar, el ejercicio útil es recorrer la cadena preguntando, capa por capa: si esto se detiene aquí, ¿quién se entera, en cuánto tiempo y qué puede hacer? Si alguna capa no tiene respuesta, ahí está el próximo incidente.

3. La degradación es un estado del producto

Un proveedor en mantenimiento no debería producir un error genérico. Debería producir una experiencia distinta y honesta: qué se puede hacer ahora, qué no, y cuándo se revisará. Construir ese estado cuesta unos días de trabajo y evita la conversación que de verdad destruye confianza, que es la de un usuario descubriendo por su cuenta que algo llevaba horas sin funcionar.

Lo que aprendes el día que cambias un proveedor

Sustituir una pieza de la cadena es la mejor auditoría de arquitectura que existe. Si el cambio obliga a reescribir textos de interfaz, a renombrar estados y a reeducar a soporte, es que el proveedor no estaba integrado: estaba incrustado. La disciplina que evita eso es aburrida y funciona: un modelo de datos propio para la operación, un vocabulario propio para sus estados, y adaptadores que traduzcan lo que dice cada proveedor a ese vocabulario.

Para el usuario, todo esto se resume en una sola cosa, que es la que realmente compra: un interlocutor. Alguien que responde por la operación completa aunque no controle todas sus piezas. Esa es, al final, la parte del trabajo que no se puede subcontratar.

Nota: contenido informativo y educativo basado en experiencia de producto. No constituye asesoramiento legal, regulatorio, fiscal o financiero ni una oferta de servicios, y no describe las obligaciones ni la actividad de ningún proveedor concreto. Las funciones reguladas, cuando existen, corresponden a la entidad autorizada correspondiente.

Fuentes

• EBA · Directrices sobre acuerdos de externalización — responsabilidad sobre funciones delegadas en terceros.
• BIS · CPMI — cadenas de intermediarios en pagos transfronterizos.
• ISO 20022 — vocabulario común de mensajería entre entidades.