Fascicolo A2P SMS per destinazione: requisiti, evidenze e responsabili

Perché un elenco di copertura non basta per autorizzare il traffico

La presenza di una destinazione in un elenco di copertura non dimostra, di per sé, che un determinato tipo di traffico sia autorizzato, che un mittente sia ammesso o che un operatore accetti una campagna. Copertura, condizioni commerciali, restrizioni dell’operatore e obblighi normativi sono aspetti distinti e vanno documentati separatamente.

Un fascicolo A2P SMS per destinazione trasforma questa distinzione in una pratica operativa: raccoglie ciò che si sa, indica ciò che manca e chiarisce chi ha verificato ogni dato e quando. Serve a supportare una decisione di lancio, non a garantire copertura, accettazione o consegna.

• Non considerare una dichiarazione commerciale di copertura come prova di autorizzazione.
• Non estendere a un altro Paese, operatore o tipo di traffico condizioni verificate altrove.
• Sospendere l’approvazione se una condizione rilevante dipende da un’ipotesi non verificata.

Cosa registrare nel fascicolo di ogni mercato

Predisponi una scheda per ciascun mercato e definiscine l’ambito. Indica il Paese o territorio, gli operatori presi in considerazione e il tipo di traffico che si intende inviare. Se l’ambito comprende solo alcuni operatori, mittenti o casi d’uso, specificalo chiaramente; evita titoli generici che possano essere interpretati come un’approvazione per l’intera destinazione.

La raccomandazione UIT-T E.164 è un riferimento pertinente per identificare il piano internazionale di numerazione pubblica, ma le informazioni disponibili non consentono di usarla come prova di autorizzazioni A2P, requisiti relativi al mittente o recapito. Mantieni questi aspetti in campi separati.

• Mercato e ambito della scheda, con data di creazione e di revisione.
• Operatori inclusi ed eventuali limitazioni note dell’ambito.
• Caso d’uso e categoria di traffico proposta, come OTP, transazionale o marketing, senza presumere che siano tutte ammesse.
• Mittente proposto e stato di verifica o registrazione, se applicabile.
• Restrizioni note, condizioni in sospeso e responsabile di ciascuna verifica.
• Fonti utilizzate, data di consultazione ed evidenze conservate.

Documentare i requisiti indicando fonte, ambito e livello di affidabilità

Per ogni requisito, registra l’affermazione precisa da valutare e le prove a suo sostegno. Annota chi pubblica la fonte, il relativo URL, la data di consultazione, l’ambito geografico e tecnico e l’operatore, il mittente o la categoria di traffico a cui si riferisce. Quando le procedure dell’organizzazione lo consentono, conserva una copia o un riferimento interno al documento consultato.

Assegna uno stato chiaro, ad esempio: confermato da fonte primaria, confermato solo per un ambito limitato, in attesa di riscontro o non verificato. Il livello di affidabilità non sostituisce le prove: deve spiegare cosa è stato verificato e quale incertezza permane.

• Collega ogni requisito a una fonte specifica, non a un elenco generico di link.
• Distingui, se note, la data di consultazione dalla data di pubblicazione o di entrata in vigore del documento.
• Registra quale aspetto è coperto dalla fonte e quali aspetti non lo sono.
• Indica chi ha interpretato le prove e chi può approvare la conclusione.
• Se non ci sono prove sufficienti, scrivi «non verificato» invece di colmare la lacuna con un’inferenza.

Distinguere normativa, condizioni degli operatori e dichiarazioni commerciali

Classifica ogni dato in base alla sua origine. Un obbligo normativo deve essere sostenuto da una fonte ufficiale pertinente al mercato. Una condizione dell’operatore deve essere attribuita all’operatore e circoscritta al servizio, al traffico o al mittente, secondo quanto documentato dalla fonte. Una dichiarazione del fornitore sulla disponibilità o sulla copertura è un’informazione commerciale: non trasformarla in un requisito confermato né in una prova normativa.

Anche i riferimenti tecnici hanno dei limiti. La pagina 3GPP fornita è un indice delle specifiche suddivise per serie e non dimostra regole nazionali per l’autorizzazione A2P. Neppure le risorse generali di GSMA sulle reti mobili confermano, da sole, le registrazioni dei mittenti, le categorie ammesse o la copertura di un mercato specifico.

Una guida del fornitore sull’A2P 10DLC menziona prove relative alle modalità di raccolta dei numeri e alla revoca del consenso in quel contesto. Considerala una guida limitata a ciò che descrive: non dimostra un obbligo universale o applicabile ad altri Paesi.

• Normativa: dai priorità al testo ufficiale e all’autorità competente del mercato.
• Operatore: conserva le comunicazioni o la documentazione attribuibili all’operatore e annota l’ambito indicato.
• Fornitore: registra la dichiarazione come informazione commerciale finché non è corroborata da prove pertinenti.
• Norma o guida tecnica: non attribuirle effetti normativi che la fonte non stabilisce.

Segnalare lacune e discrepanze senza considerarle una disponibilità confermata

Quando due fonti si contraddicono, non scegliere quella più conveniente né fare una media delle conclusioni. Registra entrambe le affermazioni, le relative date e i rispettivi ambiti; verifica se riguardano lo stesso operatore, mittente, servizio e tipo di traffico. La discrepanza potrebbe dipendere da differenze di ambito, ma non darlo per scontato senza conferma.

Rivolgiti al responsabile della conformità, al referente dell’operatore o al fornitore che ha originato l’informazione. Se la risposta non risolve la contraddizione, mantieni il dato in sospeso e limita o sospendi il lancio interessato. Un campo vuoto non equivale a un’autorizzazione.

• Annota la domanda specifica ancora da risolvere e chi deve rispondere.
• Conserva un registro delle fonti in conflitto e delle azioni intraprese.
• Non modificare lo stato in «confermato» solo perché uno strumento indica che una route è disponibile.
• Blocca la decisione se la lacuna riguarda la legalità, il mittente o l’ammissione del traffico.

Processo di approvazione e criteri per sospendere il lancio

Definisci i responsabili prima di compilare la scheda. Il team operativo può raccogliere informazioni sulla route e sull’ambito; il team di conformità può valutare le prove normative; il team di prodotto può confermare la coerenza tra caso d’uso, mittente e piano; una persona autorizzata può prendere la decisione finale. Le responsabilità specifiche dipendono dall’organizzazione e devono essere documentate.

Prima di approvare, richiedi prove sufficienti per l’ambito previsto, l’identificazione di un responsabile e una data di revisione. Se i requisiti applicabili non possono essere confermati tramite fonti affidabili, oppure se restano contraddizioni sostanziali irrisolte, sospendi il lancio o riduci l’ambito a ciò che è effettivamente supportato. Se opportuno, verifica gli obblighi consultando fonti ufficiali e un consulente locale.

• Definisci il mercato, gli operatori, il traffico e il mittente coperti dalla richiesta.
• Raccogli e classifica le prove; registra dubbi e limiti di ciascuna fonte.
• Ottieni la revisione delle funzioni responsabili e documenta la decisione.
• Autorizza solo l’ambito supportato; esplicita esclusioni e questioni in sospeso.
• Interrompi o rinvia se mancano prove pertinenti, permane un conflitto irrisolto o non è chiaro chi debba assumersi la responsabilità della decisione.

Mantenere aggiornato il fascicolo senza presumere aggiornamenti automatici

Una scheda può diventare obsoleta quando cambiano le fonti, le condizioni dell’operatore, il mittente o l’uso previsto. Stabilisci una data di revisione e assegna un responsabile che verifichi le fonti pertinenti. Non presumere che un fornitore o una piattaforma aggiorni automaticamente le informazioni, a meno che tale funzionalità non sia documentata e convalidata per il caso specifico.

Registra le decisioni e le relative motivazioni insieme alle modifiche dell’ambito. In questo modo sarà possibile ricostruire quali prove sono state utilizzate per approvare un’operazione e quali questioni erano ancora in sospeso, senza presentare una revisione precedente come una conferma attuale.

• Definisci una periodicità interna di revisione e gli eventi che impongono di riaprire la scheda.
• Annota con la data ogni modifica delle fonti, dell’ambito, del responsabile o della decisione.
• Conserva le versioni precedenti per ricostruire il contesto dell’approvazione.
• Effettua una nuova verifica prima di estendere l’ambito a un altro operatore, mittente o categoria di traffico.

Lista di controllo e limiti di ciò che la scheda dimostra

Prima del lancio, verifica che il fascicolo chiarisca chi invia quale tipo di traffico, verso quale ambito e con quale mittente; quali fonti supportano ogni condizione; cosa resta non verificato; chi ha esaminato le prove e chi ha approvato la decisione. Se una risposta importante dipende da un’ipotesi, rendila visibile e risolvila prima di procedere.

Il fascicolo migliora la governance e la tracciabilità, ma non dimostra di per sé che una route sia disponibile, che un operatore accetti il traffico o che un messaggio raggiunga il dispositivo. Le prove disponibili non consentono neppure di confermare i requisiti normativi di una destinazione specifica o di stabilire un elenco universale degli obblighi A2P per Paese.

• Ambito e caso d’uso definiti.
• Requisiti e condizioni distinti in base al tipo di fonte.
• Prove, data, responsabile e livello di affidabilità registrati.
• Lacune e contraddizioni identificate, con risoluzione o blocco documentati.
• Revisione ufficiale e consulenza locale considerate, ove opportuno.
• Approvazione limitata a ciò che è effettivamente supportato, senza promesse di copertura o consegna.