Controles de aceptación de tráfico A2P SMS: cómo validar cada flujo antes del enrutamiento
Una guía operativa para documentar propósito, remitente, destino y perfil del mensaje, aplicar controles previos al envío y gestionar excepciones sin confundir elegibilidad con calidad de ruta.
Por qué validar la admisión antes de elegir una ruta
La selección de una ruta y la admisión de un flujo son decisiones distintas. La primera compara opciones de conectividad para un destino; la segunda determina si el tráfico presentado coincide con las condiciones documentadas para ese servicio. Conviene validar primero la elegibilidad y después evaluar qué rutas disponibles son apropiadas.
Estos controles ayudan a evitar que un cambio de remitente, propósito o contenido pase inadvertido. No certifican que un mensaje vaya a entregarse ni sustituyen las obligaciones legales, contractuales o las políticas del operador aplicables al destino.
- Defina la unidad de control: cliente, aplicación, remitente, campaña o flujo identificado de forma estable.
- Separe el resultado de admisión —aceptar, rechazar o enviar a revisión— de las métricas de calidad de ruta.
- Registre las condiciones acordadas y quién tiene autoridad para modificarlas.
Qué condiciones deben quedar explícitas
Antes de automatizar controles, convierta el acuerdo operativo en campos concretos. Como mínimo, documente el propósito declarado, el remitente permitido, los destinos incluidos y el perfil de contenido esperado. Añada las condiciones que realmente formen parte del acuerdo o de las reglas aplicables; no dé por supuesto que una lista genérica cubre todos los países y operadores.
El perfil de contenido puede describir la modalidad —por ejemplo, OTP, transaccional o marketing—, la estructura esperada, el tipo de variables y la presencia de enlaces. Si hay URL, documente cuáles se permiten y cómo se declaran los enlaces, incluidos los acortados cuando corresponda. Esto es un criterio operativo útil, pero no debe presentarse como obligación universal: la CRC de Colombia describió requisitos sobre plantillas y enlaces dentro de propuestas regulatorias concretas.
- Propósito: qué uso se declara y qué usos quedan fuera del alcance acordado.
- Remitente: valor o conjunto autorizado, formato esperado y estado de autorización cuando esa información esté disponible.
- Destino: países, redes u otros ámbitos expresamente incluidos, junto con las restricciones conocidas.
- Contenido: modalidad, estructura, variables previstas y presencia de URL u otros elementos sujetos a condiciones.
- Vigencia: versión de las condiciones, fecha de revisión y responsable de su aprobación.
Cómo traducir condiciones documentadas en reglas comprobables
Cada condición debe convertirse en una prueba observable y tener un resultado definido. Por ejemplo, si el remitente debe pertenecer a una lista autorizada, compare el valor recibido con esa lista; si el destino no está cubierto por el acuerdo, detenga el envío o remítalo a revisión en lugar de inferir autorización.
No convierta una descripción ambigua en una regla permisiva. Si el acuerdo solo dice «mensajes de servicio», pero no delimita finalidades o remitentes, solicite precisión antes de ampliar la admisión. Las reglas pueden ejecutarse en un sistema propio o en el punto de integración disponible; no presuponga que una plataforma externa implementa estas validaciones automáticamente.
- Escriba cada regla como condición, fuente de datos y resultado ante coincidencia o falta de coincidencia.
- Use listas o catálogos con control de versión para remitentes, destinos y perfiles cuando el acuerdo los requiera.
- Defina qué campos son obligatorios y qué comportamiento se aplica si faltan.
- Pruebe casos permitidos, no permitidos y ambiguos antes de activar el control.
Validaciones al incorporar un cliente, remitente o flujo
Al dar de alta un flujo, solicite una ficha coherente con el acuerdo comercial y las reglas del destino. Compruebe que el propósito descrito concuerde con el perfil de contenido y que cada remitente y destino estén dentro del alcance registrado. Para cambios posteriores, compare la nueva configuración con la versión aprobada; no trate un cambio material como una simple actualización técnica.
En el caso de plantillas, una propuesta regulatoria de la CRC en Colombia describe asociar mensajes A2P con plantillas aprobadas y vigentes, respetando estructura, finalidad y modalidad declaradas incluso con campos variables. Ese documento no establece por sí solo una obligación aplicable en todos los países o rutas. También aclara que la validación descrita se refiere al contenido estático y al sentido de los campos dinámicos, no necesariamente al texto final individual ni al valor concreto de datos como un OTP.
- Confirme que la descripción del uso y el perfil solicitado no se contradicen.
- Verifique la autorización del remitente conforme al mecanismo documentado para ese destino; no suponga que existe un registro universal.
- Compruebe que el destino esté cubierto por el acuerdo y que las restricciones conocidas estén reflejadas.
- Conserve la versión aprobada del perfil, la fecha y la identidad o función de quien autorizó el alta.
Qué hacer con datos ausentes, incompatibles o ambiguos
La falta de datos no equivale a autorización. Establezca una política por campo: rechazar, poner en espera o solicitar aclaración. Para atributos que determinan la elegibilidad —por ejemplo, propósito, remitente o destino—, una revisión es más segura que completar el dato mediante una suposición.
Si dos fuentes discrepan, defina cuál es la referencia operativa vigente y quién puede resolver el conflicto. Mantenga el tráfico en revisión hasta cerrar la discrepancia cuando esta afecte el alcance acordado. Evite «arreglar» el tráfico modificando remitentes, contenido o rutas para sortear filtros o restricciones.
- Campo obligatorio ausente: no enrutar hasta obtenerlo o aplicar el procedimiento de revisión aprobado.
- Dato incompatible con el acuerdo: rechazar o suspender ese flujo y comunicar el motivo concreto.
- Información contradictoria: registrar las fuentes y escalar a la persona responsable.
- Duda sobre reglas del destino: confirmar el requisito con la parte competente antes de ampliar el alcance.
Gestión de excepciones: responsable, alcance y evidencia
Una excepción debe ser explícita, acotada y revisable. Registre quién la solicita, quién la aprueba, qué cliente y flujo cubre, qué condición modifica y durante cuánto tiempo es válida. Si no tiene vencimiento definido, establezca una fecha de revisión y evite que una excepción temporal se convierta silenciosamente en la regla general.
La evidencia debe permitir reconstruir la decisión sin conservar datos innecesarios del contenido. Guarde la referencia al acuerdo, la versión de la configuración y la justificación; limite el acceso según las políticas de privacidad y seguridad aplicables. Los requisitos concretos de retención dependen del contexto legal y contractual.
- Asigne un responsable de aprobación distinto de la ejecución automática cuando el proceso lo permita.
- Restrinja la excepción al remitente, destino, propósito y perfil afectados.
- Defina vencimiento, revisión y condiciones para revocarla.
- Registre la evidencia mínima necesaria y quién puede consultarla.
Cómo revisar cambios sin interrumpir usos legítimos
No todo cambio implica una infracción, pero todo cambio que altere las condiciones aceptadas merece una evaluación proporcional. Compare la nueva versión con la anterior y determine si cambió la finalidad, el remitente, el destino, la estructura del contenido o el uso de enlaces. Cuando el cambio no esté cubierto, solicite aclaración y aprobación antes de ampliar la admisión.
Para reducir interrupciones, comunique con antelación qué información se requiere y qué flujos quedan afectados. Si la política operativa lo permite, mantenga sin cambios los flujos ya aprobados y aísle únicamente el nuevo remitente o perfil pendiente. No prometa continuidad cuando las reglas del destino o del operador exijan otra respuesta.
- Compare versiones y clasifique el cambio como técnico, editorial o material para la elegibilidad.
- Solicite una nueva revisión cuando cambien propósito, remitente, destinos o perfil acordado.
- Defina cómo se trata el tráfico existente durante la revisión, según contrato y reglas aplicables.
- Documente la decisión y actualice las reglas solo después de su aprobación.
Registro de decisiones para auditoría operativa
Un registro útil debe explicar qué se evaluó, contra qué versión de las condiciones y cuál fue el resultado. Mantenga separados los eventos de aceptación y rechazo de las métricas de calidad: una admisión correcta no demuestra entrega, y una entrega reportada no demuestra que el tráfico estuviera autorizado.
Si se usan DLR, distinga el estado reportado por la cadena de mensajería de una recepción verificada en el dispositivo. La aceptación y las métricas de entrega, latencia o disponibilidad responden preguntas diferentes y pueden tener incertidumbre propia.
- Incluya identificador del flujo, fecha y hora, destino, versión de reglas y resultado.
- Registre el motivo normalizado de rechazo o revisión y la acción tomada.
- Vincule excepciones y aprobaciones mediante una referencia, evitando duplicar datos sensibles.
- Revise periódicamente rechazos repetidos, cambios frecuentes y reglas que generan ambigüedad.
Preguntas frecuentes
¿Estos controles son requisitos universales para todas las rutas A2P?
No. Son una práctica operativa para traducir acuerdos y reglas aplicables en comprobaciones. Las obligaciones dependen del país, el operador, el contrato y el tipo de tráfico. Las referencias de la CRC citadas describen propuestas concretas de Colombia y no prueban por sí solas una regla universal o vigente para cualquier ruta.
¿Validar un remitente demuestra que el mensaje tiene consentimiento?
No. La autorización o inclusión de un remitente en un registro no demuestra por sí sola el consentimiento del destinatario, la identidad del remitente ni la legalidad de cada mensaje. Esas cuestiones requieren controles y evidencias apropiados para el caso y la jurisdicción.
¿Un flujo aceptado garantiza que el SMS llegue al teléfono?
No. La aceptación indica que el tráfico superó los controles definidos para su admisión. No garantiza el enrutamiento, la entrega al dispositivo ni que un DLR equivalga a una recepción verificada.
¿Debe revisarse cada valor dinámico de un OTP antes de enviar?
No se puede deducir una exigencia universal de la documentación disponible. La respuesta de la CRC sobre la propuesta descrita distingue la validación de la estructura y el sentido de campos dinámicos de la revisión del valor concreto de un OTP. Aplique lo que exijan el acuerdo, las reglas aplicables y el diseño de privacidad.
¿Qué debe ocurrir si falta el propósito o el destino?
Defina previamente una política de fallo seguro: detener, poner en revisión o solicitar el dato. No infiera autorización a partir de información incompleta ni elija una ruta para evitar una restricción.
Fuentes consultadas
- Documento de soporte: Identificación de medidas para mitigar el fraude cibernético por medio de servicios móvilesComisión de Regulación de Comunicaciones (CRC), Colombia
- Documento de respuesta a comentarios sobre medidas contra fraude en servicios móvilesComisión de Regulación de Comunicaciones (CRC), Colombia