El problema real de las transferencias internacionales no es la velocidad: es la recuperación

Todo el sector vende lo mismo: rapidez. Segundos en vez de días, tiempo real en vez de dos jornadas hábiles. Es una promesa fácil de entender y fácil de medir, y por eso ocupa todas las páginas de inicio. Pero después de años construyendo producto sobre infraestructura financiera, mi conclusión es la contraria a la del argumentario comercial: la velocidad casi nunca es lo que decide si un usuario vuelve a confiar en un producto de pagos. Lo que lo decide es qué pasa el día en que una operación no llega.

Una media no es una experiencia

La velocidad es una media, y las medias esconden precisamente lo que importa. Un producto puede liquidar el 98 % de sus operaciones en segundos y aun así ser recordado por el 2 % restante, porque es ese 2 % el que genera la llamada, el correo a las tres de la mañana y la reseña. La calidad percibida de un producto financiero no la fija su mediana: la fija su peor operación.

Esto tiene una consecuencia incómoda para quien diseña. El trabajo más valioso no está en recortar dos segundos al camino feliz, sino en construir el camino que casi nadie enseña en una demo: el de una operación que se ha quedado a medias.

Dónde se pierde de verdad el tiempo

En operaciones internacionales he visto transferencias que se liquidan en treinta segundos y transferencias que tardan nueve días. La diferencia rara vez estaba en el riel. Estaba en el tiempo que tardaba alguien en saber dónde estaba el dinero: si seguía en la entidad emisora, si se había quedado retenido en un intermediario a la espera de una comprobación, o si había llegado al beneficiario pero aún no estaba visible en su extremo.

Ese hueco —el tiempo entre "algo ha fallado" y "sabemos exactamente qué ha fallado y quién responde"— es el verdadero producto. Cuando dura veinte minutos, el usuario cuenta que hubo una incidencia y que se resolvió. Cuando dura cuatro días, el usuario cuenta otra cosa, y la cuenta a todo el mundo.

Un protocolo para las primeras 24 horas

Este es el marco que uso para pensar la recuperación de una operación fallida. No es un procedimiento regulatorio ni sustituye al de ningún proveedor: es una disciplina de producto, pensada para que el tiempo de recuperación no dependa de quién esté de guardia.

1. 0 – 1 h · Detectar y clasificar Nombrar el fallo antes que explicarlo

   La operación deja de estar «en curso» y pasa a un estado explícito: retenida, rechazada, pendiente de comprobación o no localizada. Un estado ambiguo durante una hora cuesta más que un rechazo claro en diez minutos.

2. 1 – 4 h · Localizar Responder a «dónde está el dinero»

   Toda incidencia se reduce a una sola pregunta: en qué punto de la cadena se ha detenido el valor y qué entidad lo tiene en ese momento. Sin referencia trazable de extremo a extremo, esta pregunta se convierte en una cadena de correos entre operadores.

3. 4 – 8 h · Comunicar con evidencia Un mensaje que el usuario pueda reenviar

   No basta con avisar de que hay un problema. El usuario necesita algo utilizable: referencia, fecha, importe, punto de la cadena y siguiente paso previsto. Si tiene que reenviárselo a su banco o a su cliente, ese mensaje es el producto.

4. 8 – 24 h · Decidir Reintentar, devolver o escalar —pero decidir

   Pasado un umbral, mantener una operación «en revisión» deja de ser prudencia y pasa a ser una decisión no tomada. Cada caso debe salir de las 24 horas con una vía asignada y una fecha, aunque la vía sea devolver los fondos al origen.

5. Después · Registrar Convertir cada incidencia en una regla

   El caso se documenta con su causa y su resolución, y esa causa se traduce en una comprobación previa, un mensaje mejor o un cambio de proveedor. Una incidencia que no cambia nada volverá a ocurrir con otro nombre.

Qué cambia esto en el diseño del producto

• Los estados se nombran por dónde está el dinero, no por qué proveedor está involucrado. Al usuario no le sirve «pendiente en el proveedor B»; le sirve «recibido por la entidad del beneficiario, pendiente de abono».
• La referencia trazable es una función, no un detalle técnico. Si el identificador de una operación no viaja de extremo a extremo, cada consulta empieza desde cero.
• El compromiso público es de comunicación, no de liquidación. Prometer un tiempo de liquidación que depende de terceros es frágil; prometer un tiempo de primera respuesta útil depende solo de ti, y es lo que el usuario realmente está midiendo.
• La degradación es un estado del producto, no una excepción que se gestiona por chat.

Cómo se mide

Si tuviera que reducir la salud de un producto de pagos a cuatro métricas, no incluiría la velocidad media. Incluiría: tiempo hasta la primera respuesta útil; porcentaje de incidencias con el valor localizado en menos de cuatro horas; tiempo de resolución en el percentil 95 —no en la media—; y porcentaje de casos resueltos sin que el usuario haya tenido que preguntar dos veces. Esa última métrica es la que mejor predice si alguien seguirá usando el producto dentro de un año.

La velocidad se compra: se contrata un riel mejor. La recuperación se construye, y por eso es una ventaja mucho más difícil de copiar.

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 de ningún proveedor concreto. Verifica cada obligación con asesores cualificados y la autoridad competente.

Fuentes

• BIS · Comité de Pagos e Infraestructuras de Mercado (CPMI) — programa sobre pagos transfronterizos.
• Financial Stability Board — hoja de ruta del G20 para pagos transfronterizos.
• ISO 20022 — estándar de mensajería que soporta la trazabilidad de extremo a extremo.