在印度DLT体系中，金融类短信主要归属两类模板：
**Transactional(交易类)** 是银行和金融科技专属的通道。根据TRAI规定，**仅RBI正式批准/许可的银行和数字钱包**可使用此类别注册模板。其核心定义是：**任何包含OTP且用于完成由银行客户发起的银行交易的消息**。例如网银转账OTP、信用卡商户交易OTP。
**Service Implicit(隐含服务类)** 则适用于非银行交易的OTP场景，如电商登录验证、外卖配送验证码，以及银行发送的交易提醒、余额变动通知等——这些消息虽非用户主动发起的交易，但与已有客户关系相关，可合理推断同意。
两类模板的共同点是：**均可24×7全天候发送，且可穿透DND(勿打扰)限制**。而Promotional(促销类)短信则被严格限制在上午10点至晚上9点，且无法发送给DND注册号码。
| 模板类别 | 发送时段 | DND限制 | 典型场景 |
|---|---|---|---|
| Transactional（交易类） | 24×7全天候 | 可穿透DND | 银行交易OTP、支付确认 |
| Service Implicit（隐含服务类） | 24×7全天候 | 可穿透DND | 订单通知、物流提醒、非银行OTP |
| Promotional（促销类） | 仅10:00-21:00 | 不可发送至DND号码 | 营销推广、折扣活动 |
2026年1月14日起，TRAI强制要求所有新注册的DLT模板必须使用**带类型的变量标签**，取代旧版通用的`{#var#}`。对于金融OTP短信，核心标签是`{#numeric#}`。
**`{#numeric#}`的严格规则**：仅允许数字0-9，最长40字符，**不得包含字母或特殊字符**。OTP变量必须使用此标签，运行时只能填入纯数字值。
**其他可用的变量标签**包括：`{#alphanumeric#}`用于订单号、参考编号;`{#url#}`用于网页链接(最长120字符);`{#urlott#}`用于App下载链接;`{#cbn#}`用于回拨号码;`{#email#}`用于邮箱地址。
银行OTP模板示例
```
{#numeric#} is your OTP for completing net banking transaction of Rs.{#numeric#}. Valid for 10 minutes. Do not share. - YourBank
```
**关键要求**：模板固定文本中**必须出现品牌名称**(如“YourBank”)，否则审核会被拒绝。OTP变量必须使用`{#numeric#}`标签，金额变量同样使用`{#numeric#}`。
TRAI的DLT体系规范了印度短信“怎么发”，而RBI(印度储备银行)则规定了“为什么必须发”。2025年9月25日发布的 **《数字支付交易认证机制方向(2025)》** 要求所有印度数字支付交易必须通过**双因素认证(2FA)** 。
RBI明确指出，虽然未强制指定具体认证因素，但数字支付生态已**主要采用基于短信的OTP作为附加因素**。该方向自**2026年4月1日起生效**，适用于所有支付系统提供商和参与者(包括银行和非银行实体)。
这意味着：**对于印度金融交易而言，OTP短信不是“可选项”，而是RBI监管框架下的强制合规要求。**
违反TRAI交易短信规定的后果是分级递进的：
| 违规类型 | 处罚措施 |
|---|---|
| 使用未注册模板发送 | 运营商直接拦截，短信无法送达 |
| 交易模板中出现促销词 | 模板被拉黑，需重新注册 |
| 首次违规（AI标记+10天内3起投诉） | 所有号码和线路暂停15天 |
| 重复违规 | 号码和线路可能被切断一年，发送方被列入黑名单 |
| 未保留用户同意记录 | DPDP法案罚款最高₹50亿（约600万美元） |
1. **确认模板类别资格**：使用Transactional模板需RBI批准，非银行企业应使用Service Implicit
2. **OTP必须使用`{#numeric#}`标签**：仅允许数字0-9，不得包含字母或链接
3. **品牌名称必须出现在模板固定文本中**
4. **URL和回拨号码提前在DLT平台白名单化**
5. **完整留存OTP发送日志和用户同意记录**，以备RBI审计
6. **确保₹500以上电子银行交易自动触发短信提醒**
**一句话总结**：印度金融OTP短信的合规核心是 **“RBI要求必须发，TRAI规定怎么发”** ——2FA框架强制交易必须通过OTP认证，而DLT的Transactional模板和`{#numeric#}`标签规范则决定了这条短信能否成功送达。
