Transactional, OTP or Marketing: An Operating Framework for Classifying A2P SMS Traffic Before Sending

Classification Must Come Before Routing

A2P SMS traffic classification is not a commercial label added at the end of the process. It is an operational governance decision that should be made before selecting a route, sender, template, frequency policy or incident-handling approach.

A single messaging programme may contain different use cases. For example, account access may require an OTP, a purchase may generate a functional confirmation, and a later campaign may promote products or services. Grouping all three under a generic label such as “notifications” makes it harder to apply consistent controls and demonstrate why each message was appropriate.

The decision should be linked to the use case, not only to the individual message. This allows operations, product, compliance and routing teams to work from a shared definition that can be reviewed when the template, trigger, destination country or contact base changes.

• Classify before sending, not after observing technical results.
• Apply the classification to the use case and its generation rules.
• Review the classification when content, purpose, destination or product flow changes.
• Do not use a category as a reason to bypass requirements that apply in a market or on a route.

Three Operational Categories: OTP, Transactional and Marketing

OTP, transactional and marketing describe different operational purposes. The distinction does not depend only on a word in the message, an internal campaign label or whether the message is sent automatically.

An OTP is tied to a specific authentication or recovery operation and delivers a short-lived secret. A transactional message communicates information required following a service event. A marketing message aims to promote, persuade or drive a commercial action among an audience.

These categories may be subject to different rules depending on the country, operator, route and relationship with the recipient. Internal classification should therefore be conservative and does not replace review of the requirements that apply in each destination.

• OTP: enables an authentication or recovery operation through a limited-use secret.
• Transactional: provides information about a service event and is limited to what is necessary for that event.
• Marketing: includes a promotional, persuasive or commercial purpose, even when sent to existing contacts.

Text Alone Does Not Determine the Category

Words such as “code”, “confirmation”, “alert” or “offer” provide signals, but they do not determine classification by themselves. A message containing a code is only an OTP if a specific authentication operation triggered it, the code enables that operation, and the flow applies appropriate controls for validity, use and retries.

Likewise, an order confirmation may be functional if it communicates information required about a completed purchase. If it adds a cross-sell, discount or invitation to buy again, it includes a promotional purpose that should be assessed separately.

Classification should consider the full flow: who receives it, what event triggers it, what action it enables, what relationship justifies it and what commercial component it contains.

• Do not classify a message as OTP merely because it includes numbers or the word “code”.
• Do not classify a campaign as transactional merely because it targets existing customers.
• Do not retain a functional classification if a new template version adds commercial persuasion.
• Document the relationship between the message and the event or transaction that triggered it.

Four Questions for Classifying Each Use Case

A repeatable framework starts with four questions. They should be answered for every use case, template and relevant destination, rather than through broad assumptions about the brand or industry.

The first question is what triggers the message. The second is what action it enables or what necessary information it provides. The third is what relationship with the recipient justifies the contact. The fourth is whether the content includes promotional or persuasive value.

If the answers change because of a product change, new automation or template variation, the use case should be reviewed again.

• What triggers it? Examples include an access request, completed purchase, service status change or planned campaign.
• What action does it enable? Authentication, account recovery, checking service information, completing a contractual action or making a purchase.
• What relationship justifies it? A user-initiated request, an existing transaction, a service relationship or a documented contact base.
• What promotional value does it include? Discounts, calls to buy, commercial recommendations, incentives or cross-sells.

OTP Framework: Specific Authentication, Context and Retry Controls

An OTP should be associated with a specific authentication or recovery operation. NIST describes out-of-band authentication as an operation bound between the primary and secondary channels, not simply the sending of a code by SMS. OTP classification therefore requires recording the request that generated the message and the action the secret will allow the user to complete.

Content should be brief and contextual. The recipient should be able to recognise the service and the request to which the code relates. NIST states that out-of-band messages should include contextual information, such as the name of the service being accessed.

Secrets should be designed for limited use. NIST states that, in out-of-band authentication, a secret must be accepted only once and authentication must not be considered valid if it is not completed within ten minutes. It also requires random secrets of at least six decimal digits or an equivalent value.

Retry controls should not be handled only by resending messages. NIST requires rate limiting when the secret has fewer than 64 bits and states that generating a new secret must not reset the failed-attempt counter. Resend, validation and lockout rules should belong to the authentication flow and be correlated with the original event.

SMS OTP should not be presented as phishing-resistant authentication. NIST expressly states that out-of-band authentication is not phishing-resistant. When the public telephone network is used to deliver a secret, NIST also requires alternative authentication methods for subscribers and recommends considering risk signals, such as device changes, SIM changes, number porting or other anomalous behaviour before sending.

• Link each OTP to an identifiable authentication or recovery request.
• Include recognisable context about the service and requested operation.
• Use a random, single-use secret with a limited validity period.
• Apply attempt limits and do not reset the counter when generating a new code.
• Control resends and assess risk signals before delivering the secret where appropriate.
• Do not add discounts, offers, recommendations or other commercial incentives to the OTP template.
• Maintain alternative authentication methods for users.

Transactional Message Framework: Service Event and Essential Information

A transactional message communicates information required about a service event. It may be, for example, an order confirmation, status change, operational alert or reminder linked to a service relationship. Classification depends on the event existing, being identifiable and justifying the send.

The template should be limited to information essential for the recipient to understand the event or act on it. If the primary purpose is to inform about a purchase, service or action already initiated, the message may remain in this category within an operational framework. If the template aims to generate an additional purchase, attract commercial attention or encourage a new decision, it should be reviewed as marketing or as a mixed message.

It is advisable to record the event reference: an order, incident, appointment, account or internal process identifier, as appropriate. All of these details do not need to appear in the SMS text, but internal evidence should exist to connect the message with the event that caused it.

• Require a verifiable service trigger.
• Limit the template to useful information necessary for that event.
• Keep a correlation reference between the message and its source event.
• Review any change that introduces recommendations, incentives, cross-selling or commercial calls to action.
• Do not assume that an existing relationship removes applicable privacy or commercial communications requirements.

Marketing Framework: Promotion, Persuasion and a Documented Audience

A message should be treated as marketing when its purpose is to promote an offer, persuade someone to buy, recommend a product or service, reactivate an audience or drive a commercial action. The classification remains marketing even when the recipient is already a customer, the message contains useful information or it is scheduled as part of an automation.

Operations should document the promotional purpose and the contact basis applicable to the destination. The European Union data protection framework regulates the processing of personal data; therefore, reusing a database for promotion requires that the purpose and applicable basis be appropriately recorded for the relevant country.

Marketing requires specific audience and suppression controls. Before sending, the team should be able to determine which segment receives the communication, why it is eligible, what restrictions apply, and how applicable opt-out requests or suppression statuses will be handled.

• Classify discounts, offers, recommendations, purchase invitations and reactivation campaigns as marketing.
• Keep the purpose and contact basis applicable to the destination documented.
• Apply suppression lists and eligibility rules before building the final audience.
• Define frequency and timing policies that are compatible with applicable requirements and the recipient experience expected.
• Review senders, templates and routes according to country restrictions and the connectivity used.

Edge Cases and Mixed Messages

Edge cases require analysis of the dominant purpose and every component of the content. An order confirmation without promotional elements may be transactional. The same confirmation with a cross-sell offer already contains a marketing component. Retaining the transactional label simply because it includes order details is not a sufficiently prudent decision.

A renewal reminder may be functional if it communicates a date, status or required action within an existing service. If it becomes an invitation to purchase an upgrade, extend a plan or take advantage of a discount, it should be reviewed for its promotional component.

Balance alerts, invitations and account recovery also require context. A service alert may be functional; an invitation intended to acquire new users normally has a promotional purpose; and an account recovery message that adds an offer should not automatically retain an OTP or transactional classification.

For a mixed message, there are three prudent operational options: separate the sends, remove the promotional component from the functional message, or apply the most restrictive applicable regime to the entire message. The choice should be documented.

• Order confirmation with a cross-sell: separate the confirmation and promotion, or treat the full message using applicable marketing controls.
• Renewal reminder: keep it functional only when it informs about the service without additional commercial persuasion.
• Balance alert: assess whether it communicates a service fact or drives a purchase or top-up through an incentive.
• Invitation: analyse whether it is a necessary communication within an existing relationship or an acquisition activity.
• Account recovery with an offer: separate the recovery secret or instruction from any promotion.