Restricciones de rutas SMS A2P: cómo documentarlas para evitar envíos no compatibles y decisiones de enrutamiento opacas

Por qué las restricciones de ruta deben ser datos operativos

Una restricción de ruta SMS A2P es una condición que determina si un mensaje concreto puede enviarse mediante una ruta determinada. Puede depender del destino de terminación, del operador cuando corresponda, del tipo de tráfico, del remitente, del contenido, del registro previo, de la capacidad disponible o de una condición comercial.

Estas condiciones suelen estar repartidas entre contratos, correos electrónicos, portales de proveedores, tickets y el conocimiento informal de un miembro del equipo. Este modelo es difícil de auditar y propenso a errores: una ruta puede estar disponible técnicamente sin admitir un destino, Sender ID, tráfico promocional, enlaces o patrón de volumen determinados.

La matriz de restricciones no sustituye al contrato, la normativa aplicable ni la confirmación del proveedor. Su propósito es convertir información dispersa en reglas que puedan consultarse, rastrearse y aplicarse antes de aceptar, enrutar o escalar tráfico.

• Trata cada restricción como una regla con alcance explícito, no como una nota genérica.
• Modela específicamente el destino de terminación; no deduzcas requisitos solo a partir del país de origen del remitente.
• Utiliza numeración internacional normalizada como campo de validación del destino, conforme a la Recomendación ITU-T E.164 para el plan público internacional de numeración.
• Mantén separadas las restricciones técnicas de SMS, las condiciones comerciales de ruta y los requisitos regulatorios o de red.

Una ruta disponible no es necesariamente una ruta adecuada

La disponibilidad de conectividad no demuestra que una ruta sea adecuada para todo el tráfico. Una misma ruta puede aceptar una conexión HTTP o SMPP y, aun así, restringir remitentes, requerir prerregistro, admitir solo ciertos casos de uso o aplicar límites de capacidad distintos por cuenta, remitente o canal.

La decisión correcta no consiste simplemente en preguntar si existe una ruta hacia un país. Debe formularse como una evaluación de compatibilidad: ¿este destino, este remitente, este caso de uso, este contenido y este patrón de envío están admitidos por esta ruta en la fecha de la decisión?

Este enfoque evita una conclusión especialmente arriesgada: interpretar una condición comercial o una afirmación de disponibilidad como una garantía técnica de entrega. Aunque un mensaje sea aceptado para su procesamiento, el resultado puede depender de elementos fuera del control de una sola parte de la cadena de mensajería.

• Destino: país y, cuando la evidencia lo requiera, red u operador de terminación.
• Tráfico: OTP o 2FA, notificación de cuenta, alerta de fraude, atención al cliente, marketing con consentimiento u otra categoría controlada.
• Remitente: alfanumérico, número, código corto u otro tipo de remitente permitido por el destino y la ruta.
• Contenido: idioma, codificación, enlaces, acortadores, plantillas, texto de baja y elementos de marca.
• Patrón de envío: volumen, velocidad, recurrencia, ventana de validez y requisito de respuesta.
• Condiciones de incorporación: prerregistro, aprobación, campaña, consentimiento y pruebas requeridas.

Categorías mínimas para una tabla de restricciones

Una tabla útil debe permitir que operaciones, compras, cumplimiento e ingeniería respondan a la misma pregunta utilizando los mismos campos. Una simple columna de «permitido» o «no permitido» es insuficiente porque esa respuesta carece de contexto y no explica qué cambia la condición.

El nivel de detalle debe ser suficiente para evitar reglas demasiado genéricas a nivel de país. Si una condición solo se ha confirmado para un operador, red o tipo de remitente, el registro debe reflejar ese límite en lugar de extenderlo a todo el destino.

La conectividad solo debe registrarse cuando afecte a la aceptación operativa del tráfico y exista evidencia específica de la ruta o proveedor correspondiente. La disponibilidad de HTTP o SMPP no confirma por sí sola que un tipo de tráfico esté permitido.

Una consulta HLR puede utilizarse como señal técnica de red dentro de una decisión operativa, pero no demuestra consentimiento, identidad, titularidad del número ni entrega garantizada. Las observaciones técnicas internas, incluidas las pruebas acotadas por fecha, ruta, destino u operador, no constituyen verificación independiente ni prueba suficiente de cumplimiento, elegibilidad comercial, consentimiento o entrega real. Deben evaluarse separadamente de la evidencia contractual, regulatoria y de aprobación aplicable.

Antes de comprar o vender capacidad A2P, conviene verificar el alcance de cada restricción, la evidencia disponible y su vigencia. Las reglas precisas y actualizadas reducen la ambigüedad en una gestión responsable de capacidad.

• Identificador de regla: código único y estable para referencias en tickets, controles y cambios.
• Destino: país, prefijo o patrón de numeración aplicable y formato esperado.
• Operador o red: obligatorio solo cuando la condición se haya verificado a ese nivel.
• Ruta o relación comercial: identificador interno de ruta y alcance de la condición.
• Tipo de tráfico: valor controlado, no una etiqueta de texto libre.
• Tipo y valor del remitente: clase de remitente, restricciones de longitud o formato y capacidad de respuesta cuando corresponda.
• Contenido: requisitos sobre plantillas, enlaces, dominios, acortadores, idiomas o categorías no admitidas.
• Conectividad: protocolo, parámetros o limitaciones de integración que afecten a la aceptación operativa del tráfico, cuando estén documentados para la ruta específica.

Declarado, verificado y pendiente de confirmación

La calidad de una matriz depende tanto de lo que registra como de la forma en que expresa la certeza. Una regla declarada por un proveedor, un requisito confirmado por documentación oficial y una condición observada en una prueba no tienen el mismo valor probatorio.

Utiliza estados explícitos de evidencia. Esto evita que un equipo convierta una afirmación comercial en un hecho verificado o una observación técnica limitada en una regla universal. El estado debe acompañar a cada restricción y no aparecer solo en una nota general de ruta.

• Declarado: condición comunicada por la contraparte, pendiente de validación independiente o de evidencia documental suficiente.
• Verificado: condición respaldada por una fuente primaria, aprobación documentada, cláusula aplicable o evidencia operativa con alcance definido.
• Pendiente de confirmación: información incompleta, contradictoria, caducada o sin aplicabilidad clara para el caso de uso.
• No aplicable: la condición se evaluó y no aplica al alcance de ese registro; debe incluir justificación.
• Retirado o sustituido: regla histórica que no debe utilizarse para decisiones nuevas y se conserva con fines de auditoría.

Sender ID, prerregistro y capacidad de respuesta

El remitente debe documentarse como un objeto sujeto a reglas, no como texto introducido al final del flujo de trabajo. El registro debe indicar qué tipo de remitente se utilizará, si está permitido en el destino, si necesita registro previo y qué evidencia demuestra su estado.

Los Sender ID alfanuméricos merecen atención específica. Normalmente se utilizan para mensajería unidireccional y deben tratarse como tales salvo que el tipo de remitente, el destino y la ruta aplicables admitan expresamente respuestas. La documentación de Twilio indica que los Sender ID alfanuméricos no están disponibles para destinos en Estados Unidos o Canadá; esta condición se limita al proveedor documentado y debe verificarse en la fecha de consulta, sin extrapolarse automáticamente a otras rutas o proveedores.

Cuando aplique el prerregistro, registra el identificador de solicitud o campaña, estado, fecha de aprobación, entidad aprobadora, fecha de expiración cuando corresponda y los mensajes o dominios cubiertos. Un remitente activo o registrado no demuestra por sí solo que todo el tráfico asociado esté admitido.

• Nombre o valor de remitente solicitado y valor efectivamente aprobado.
• Tipo de remitente y si admite mensajes entrantes o respuestas.
• Requisito de prerregistro por destino y estado de la solicitud.
• Marca, caso de uso, muestras de mensajes, enlaces y palabras clave cuando formen parte del proceso aplicable.
• Fecha de incorporación, vigencia, renovación y responsable de revisar el estado.
• Restricciones que vinculen el remitente a una campaña, dominio, tipo de tráfico o ruta específicos.

Clasifica el tráfico antes de aplicar reglas

La categoría de tráfico no debe ser un campo de texto libre como «transaccional» sin definición. Una clasificación controlada permite aplicar restricciones coherentes e identificar cuándo un flujo mixto requiere revisión adicional.

En el marco estadounidense de campañas A2P, las categorías documentadas incluyen 2FA, notificaciones de cuenta, atención al cliente, alertas de fraude, marketing y campañas mixtas. La clasificación aplicable depende del destino, del marco de registro, del carrier, del CSP, del registro y de la fecha; por ello, la matriz debe conservar el catálogo utilizado, su fuente y sus condiciones aplicables.

Para tráfico recurrente, la documentación debe separar el mecanismo de alta, el mecanismo de baja y la asistencia. En la guía de The Campaign Registry, el opt-in es obligatorio para casi todos los tipos de campaña, mientras que los elementos de opt-out y HELP tienen requisitos propios. En Estados Unidos, las solicitudes de revocación de consentimiento sujetas a la TCPA deben tratarse como eventos operativos: la FCC exige atenderlas en un plazo razonable que no exceda diez días laborables desde su recepción.

• OTP o 2FA: define el evento que genera el código, la vigencia esperada y el remitente autorizado.
• Alertas transaccionales: describe el evento de cuenta, pedido, seguridad o servicio que activa el mensaje.
• Marketing con consentimiento: documenta el flujo de consentimiento, frecuencia, mensaje de alta, baja y ayuda cuando corresponda.
• Atención al cliente: define si existe una conversación, qué remitente se utiliza y qué contenido está permitido.
• Tráfico no admitido: utiliza una categoría explícita para prohibiciones confirmadas; no lo dejes como excepción implícita.
• Tráfico mixto: exige revisión humana cuando se combinen finalidades o la clasificación no esté clara.

Contenido, enlaces y mecanismos de baja

El contenido debe evaluarse como texto final renderizado. Las variables de personalización pueden introducir caracteres, enlaces o longitud adicional que no estaban presentes en la plantilla base. Validar únicamente la plantilla incompleta puede provocar una clasificación incorrecta de la codificación o incumplir una condición de ruta.

Documenta por separado las restricciones de contenido verificadas para cada destino o campaña: plantillas requeridas, muestras de mensajes aprobadas, dominios, enlaces, acortadores, marcas y palabras clave. Si no existe evidencia suficiente para una categoría, marca la condición como pendiente de confirmación en lugar de convertirla en una prohibición o permiso universal.

Una DLR con estado de entregado no valida el contenido, el consentimiento, el prerregistro ni la idoneidad de la campaña. Es un estado de entrega comunicado por la cadena de mensajería; el cumplimiento requiere evidencia propia.

• Conserva las muestras aprobadas junto con la versión de la campaña o del remitente.
• Registra dominios y enlaces aprobados cuando lo exija el marco aplicable.
• No supongas que un acortador está permitido solo porque otro enlace haya sido aceptado.
• Para campañas recurrentes, vincula las instrucciones de baja y ayuda con la evidencia del flujo de alta.
• Registra las solicitudes de baja recibidas, su fecha de recepción, el sistema responsable y la fecha de ejecución.
• Distingue una DLR comunicada por un proveedor de una recepción verificada de forma independiente en el terminal; no son equivalentes.

Límites técnicos: documentar sin prometer entrega

Los límites técnicos son necesarios para decidir si un mensaje puede procesarse como se espera, pero no deben expresarse como garantías de entrega. La implementación técnica de SMS se rige por especificaciones como 3GPP TS 23.040, que continúa bajo control de cambios, mientras que los límites efectivos de una plataforma o ruta pueden añadir sus propias condiciones.

Como referencia técnica documentada por Twilio, un SMS GSM-7 admite 160 caracteres en un segmento y UCS-2 admite 70. En mensajes concatenados, las referencias son 153 caracteres GSM-7 y 67 UCS-2 por segmento. Un solo carácter fuera del conjunto GSM-7 puede hacer que el mensaje completo pase a UCS-2 y cambie el número de segmentos.

La velocidad de envío, la capacidad y el tiempo en cola también requieren contexto. Un límite de TPS o MPS debe incluir alcance, fecha de verificación y condición aplicable porque puede depender de la cuenta, el remitente y el canal. Superar el límite puede provocar encolamiento. La ventana de validez también debe registrarse: una cola puede expirar antes si se establece un Validity Period más corto. Como ejemplo específico de proveedor, la documentación de Twilio indica, en la fecha de consulta correspondiente, que los mensajes no pueden permanecer en cola más de diez horas; esta limitación no debe aplicarse como regla general a otras plataformas o rutas.

• Codificación esperada: GSM-7, UCS-2 u otra condición documentada por la plataforma.
• Longitud y segmentación calculadas sobre el texto final renderizado.
• Política de concatenación y tratamiento de mensajes multipartes.
• TPS o MPS: valor, unidad, alcance, fuente, fecha y comportamiento al superar el umbral.
• Ventana de validez: valor solicitado, límite admitido y consecuencia de expiración.
• DLR: estados disponibles, origen de recepción y limitaciones de interpretación.