Quick answer: Phase II of India's Digital Personal Data Protection Act (DPDP) takes effect 13 November 2026, and it moves consent from something a sender asserts to something a sender proves. Any business sending A2P SMS into India should expect proof of consent — not its own log line, but a cryptographically signed consent receipt minted by a registered Consent Manager — to be the artifact that answers "show me this recipient consented." The mechanism is a small one: a trusted intermediary's digital signature over a canonical form of what the recipient agreed to. Devotel Orbit now ships the verification and storage surface for those receipts, so a sender that already has consent-manager integration wired can deposit and re-verify receipts alongside its ordinary per-contact consent records. None of it is mandatory inside Orbit — the registration, the receipt collection, and whether you use the flow at all are tenant decisions. This post is the news context, the mechanism in business language, and a pre-deadline checklist.
The news: DPDP Phase II makes consent provable through registered intermediaries
India's DPDP Act (2023) introduced the Consent Manager — a regulated, registered intermediary that sits between the individual (the data principal) and the business processing their data (the data fiduciary). Phase I put the framework in place; Phase II, effective 13 November 2026, is where the agreement layer turns into an operational mandate and the consent-manager mechanism becomes the standard route for verifiable consent evidence.
For the SMS layer this lands on top of an existing regime. India already runs A2P SMS through TRAI's DLT registration: the sender's Principal Entity, every sender header, and every content template are registered artifacts, and consent templates were part of that registration already. Phase II raises the consent template into a live receipt flow: the consent has to be captured through a consent manager, and the receipt it issues has to be storable, checkable, and audit-ready.
Under the Act the data fiduciary (the sending business) remains responsible for proving consent — and the penalty scale reaches INR 250 crore for violations. Nobody's DLT onboarding, operator chain, or platform relationship transfers that responsibility. The practical reading for SMS senders: a consent timestamp in your own database is an argument; a signed receipt from a registered consent manager is evidence.
How the consent-manager model works, in business terms
Four roles, two artifacts:
- Data principal — the individual. They grant, review, and withdraw consent through the consent manager's interface, not through each business separately.
- Consent Manager — a registered, accountable intermediary. Its job is to hold the individual's standing answers, apply them to a business's request, and — the part that changes operations — sign the outcome.
- Data fiduciary / data processor — the business and its processors. They ask for consent, receive the signed receipt back, and are expected to keep that receipt as the proof of what was granted.
- The receipt — tells you what was consented to: purpose, channels or scope, issue time, identifiers of the parties. The signature tells you who attests it: the consent manager's private key, checked against its published public key.
Two properties make the mechanism behave. First, tamper-evidence: the signature covers a canonicalized form of the receipt — key order and whitespace normalized so the same content always signs to the same bytes (Orbit's verifier uses a sorted-key, whitespace-dropped JSON form modelled on JCS/RFC 8785). Rewrite one purpose string and the signature stops verifying. Second, provable provenance: the signature verifies with ECDSA over the P-256 curve against the consent manager's registered public key, so the receipt cannot be re-attributed to a different issuer, and anyone holding the receipt and the manager's public key can re-verify it at audit time — including in legal or regulatory discovery.
The business-language summary: the consent manager is a licensed notary for consent, and the signed receipt is the notarized record. Everyday consent capture keeps working the way it already does on your own surfaces; the DPDP flow is the india-facing evidence layer on top.
What Orbit ships: the consent-manager registry and signed-receipt verification surface
Devotel Orbit's compliance API now covers the two halves of that flow — registering the consent managers your recipients go through, and verifying + storing the receipts those managers issue. Three endpoints, rooted at POST /api/v1/compliance/consent/...:
- Register a Consent Manager —
POST /api/v1/compliance/consent/managers(admin/owner scoped): stores the manager's identity, endpoint, and public key (ECDSA P-256, SPKI PEM).GETlists registered managers;PUTupdates or deactivates one. - Store a signed receipt —
POST /api/v1/compliance/consent/receipts: verifies the manager signature against the registered public key before anything is stored, then persists the verified receipt as a per-contact consent record, alongside the ordinary opt-in/opt-out records for that contact and channel. A bad signature or an unregistered or inactive manager returns422 CONSENT_RECEIPT_INVALID— nothing lands in the ledger from an unverifiable receipt. - Re-verify a stored receipt —
POST /api/v1/compliance/consent/receipts/:id/verify: re-checks a stored receipt against the manager's current key. This is the audit-time answer: the receipt still verifies, and the manager that signed it is still active (or has rotated keys — where the response tells you).
The exact request shapes, the canonicalization rules your consent manager must sign against, and the pre-migration tenant behaviour are on the consent management & receipts page.
Two framing points, stated plainly rather than implied. First, the surface is optional: Orbit does not gate India-bound sends on DPDP receipts and does not claim the platform requires this flow. The DLT registration regime already applies at the operator layer; the receipt surface is there for senders who choose to collect DPDP receipts through a consent manager. Second, the flow is tenant-owned: the tenant registers the managers, the tenant collects and deposits the receipts, and the tenant decides which traffic actually requires them. Orbit provides the verification and storage surface — choosing and operating the consent-manager relationship is the tenant's work.
Who is affected, and what to do before 13 November 2026
Phase II matters to you if any of these hold:
- You send A2P SMS into India — marketing or transactional traffic terminating on Indian numbers.
- You are a DLT-registered Principal Entity — the DPDP evidence layer rides on top of the DLT registration you already maintain.
- You process personal data of individuals in India through any Orbit channel — SMS is the most immediate surface, but the consent-receipt artifact is channel-agnostic once stored.
A pre-deadline checklist, in order:
- Confirm your DLT posture. Principal Entity, headers, and content/consent templates registered and current. If that layer is stale, fix it first — it is the operator-side gate that already holds traffic today. The DLT-India onboarding guide walks the artifacts Orbit mirrors and the portal sequence itself.
- Pick your consent-manager relationship. If your recipients will grant consent through a registered consent manager, register that manager in Orbit with its public key (
POST /compliance/consent/managers). - Wire receipt capture into your consent flow. Where a consent manager issues a signed receipt, deposit it (
POST /compliance/consent/receipts) — the signature is verified at intake, so only verifiable receipts enter the ledger. - Plan the audit path. Receipts sit next to ordinary consent records, so your existing consent export and history reads cover them; re-verify on schedule (
POST /compliance/consent/receipts/:id/verify) against the manager's current key. - Keep the ordinary consent layer honest. The receipt is the evidence; the per-contact consent records and your send-gate policy still define who you may actually message. Orbit's send gates stay tenant-owned controls on top of all of this.
Operators and regulators run on artifact timelines, not announcement timelines — the senders who will have a calm November are the ones whose receipts are already landing in September.
Frequently asked questions
Does Orbit require signed consent receipts for India sends?
No. Orbit does not gate outbound on a DPDP receipt check. The Consent Manager surface is an optional, tenant-owned capability; DLT registration is enforced by the Indian operators at the network layer, not by the platform. Whether your traffic collects receipts is your compliance decision.
What exactly is a consent receipt?
A signed statement, issued by a registered consent manager, of what a data principal agreed to — purpose, scope, issue time, and the parties involved — plus an ECDSA P-256 signature over the canonicalized content. It is evidence the sender stores and can re-verify, not a log line in the sender's own database.
We already record opt-ins through Orbit's consent API. Is that still valid?
Yes — unchanged. The per-contact opt-in/opt-out ledger is the system of record for who your send gates may message. The signed receipt is an India-specific evidence layer for DPDP Phase II that deposits into the same ledger when you choose to use it; it does not replace ordinary consent capture.
Do we still need DLT registration if we use consent receipts?
Yes. DLT (Principal Entity, headers, templates) and DPDP consent receipts answer different questions: DLT is the operator-side registration regime that already gates delivery, DPDP is the consent-evidence layer. Both apply to Indian A2P SMS.
Who registers the consent manager — Orbit or us?
You do. The tenant registers each consent manager with its public key (admin/owner-scoped call), and the tenant collects and deposits receipts. Orbit verifies and stores; the consent-manager relationship and the decision to use the flow are yours.
The takeaway
Phase II turns Indian SMS consent from self-attestation into signed evidence: receipts minted by registered consent managers, verifiable against published keys, re-checkable at audit time. Orbit's shipped surface covers exactly the part a platform should own — register the manager, verify the signature before anything is stored, persist the receipt into the consent ledger, re-verify on demand — and you can read the full contract on the consent management page and pair it with the DLT-India onboarding for the registration layer. The choice to use it, and the posture behind it, stay where compliance always lives: with the tenant.