160 Series IVR and Dialer Setup: Complete Technical Guide for BFSI India

Key Facts at a Glance

Item	Detail
Regulation	TCCCPR, 2018 (Second Amendment, 12 Feb 2025)
Governing body	TRAI / DoT
Applies to	Banks, NBFCs, AMCs, stockbrokers, insurers, pension funds, and their BPO/recovery agents
Number series	160xxxxxxx (service/transactional) | 1601xxxxxxx (RBI/SEBI/PFRDA/IRDAI financial entities)
First-violation penalty	Rs 2,00,000
Blacklist trigger	5 valid complaints in any rolling 10-day period; up to 1-year blacklist across all TSPs
Key technical requirement	DLT template registration + SIP CLI = 1600 number + segregated routing trunk + CDR logging

160 series IVR and dialer setup is now a legal obligation for regulated BFSI entities in India, not an optional infrastructure upgrade. The Department of Telecommunications (DoT) formally allocated the 160xxxxxxx numbering series on 30 May 2024 (PRID 2022249), and TRAI issued a binding Direction on 19 November 2025 (PRID 2191647) converting voluntary adoption into a time-bound mandate. For IT teams and operations heads at banks, NBFCs, insurance companies, and their BPO partners, the challenge is not understanding the policy but translating it into working infrastructure. This guide covers every technical layer of 160 series IVR and dialer setup: TSP application, SIP trunk configuration, DLT template registration, CDR logging, and routing segregation to API integration.

• 160 series IVR and dialer setup involves five distinct technical layers: TSP allocation, SIP trunk configuration, DLT template registration, dialer routing segregation, and CDR logging.
• Every IVR voice script, agent introduction, and automated message used on a 1600/1601 number must carry a pre-registered DLT Template ID passed in call signalling.
• The same dialer instance cannot route both 140 promotional traffic and 1600 transactional traffic through the same number pool. Routing segregation must be a system-level technical control, not a written policy alone.
• A standard migration from 10-digit numbers to the 160 series typically takes 4 to 8 weeks without specialist support. FreJun reduces this to 48 hours with a pre-configured 160 series environment.
• Failure to configure correctly exposes the entity to Rs 2,00,000 first-violation penalties and a 1-year all-TSP blacklist if complaint thresholds are crossed.

Table of Contents

1. What Is the 160 Series Number and Why Does Your IVR Need It?
2. Step 1: Applying to Your TSP for a 160 Series Number
3. Step 2: SIP Trunk and PRI Configuration for 160 Series CLI Presentation
4. Step 3: DLT Platform Registration and 160 Series IVR Script Template Approval
5. Step 4: 160 Series Dialer Routing Segregation from 140 Traffic
6. Step 5: CRM and API Integration for 160 Series Outbound Calls
7. Step 6: CDR Logging, Call Recording, and Audit Trail Requirements
8. Step 7: Pre-Go-Live Testing for 160 Series IVR Compliance
9. BPO and Recovery Agent Technical Configuration for the 160 Series
10. How FreJun Makes 160 Series IVR Setup Faster
11. Frequently Asked Questions
12. Key Takeaways
13. Compliance Disclaimer
14. References and Sources

Quick Answer: 160 series IVR and dialer setup requires five layers: a TSP allocation with eligibility verification, a SIP trunk presenting the 1600 CLI, DLT template approval for every IVR script, segregated routing keeping promotional and transactional traffic on separate trunks, and CDR logs mapped to Template IDs. Without all five layers, your entity is not technically compliant even if the 1600 number has been issued.

What Is the 160 Series Number and Why Does Your IVR Need It?

Your IVR needs a 160 series number because the TRAI Direction of 19 November 2025 now classifies any service or transactional call from a non-160 number class as Unsolicited Commercial Communication from an Unregistered Telemarketer (UTM). Additionally, your customers already distrust calls from standard 10-digit numbers purporting to be from their bank or insurer. Fraudsters exploited that format for years, and the 160 series IVR and dialer setup exists precisely to close that trust gap.

Furthermore, migrating your IVR to a 1601 number produces a measurable improvement in call pick-up rates. Industry reports indicate that recognisable, verified caller IDs consistently outperform anonymous numbers in consumer answer-rate studies. Consequently, that improvement directly benefits collections, OTP delivery, and policy renewal workflows.

In my practice advising telecom-sector clients, I see this pattern repeatedly. Entities that complete the full 160 series IVR and dialer setup report not just compliance peace-of-mind but also a tangible operational improvement within the first billing cycle. Therefore, the technical investment in a proper 160 series setup pays for itself faster than most compliance officers initially expect.

FreJun provisions 160 series numbers, pre-configures the SIP trunk, and manages DLT template registration for BFSI entities. Most teams go live in 48 hours with no disruption to existing call workflows. No infrastructure investment is required on your side.

Talk to FreJun’s Legal Team

Step 1: Applying to Your TSP for a 160 Series Number

The first step in any 160 series IVR and dialer setup is obtaining the number itself. A 1600/1601 number is a regulated telecom resource. Your TSP allocates it only to verified Principal Entities. You cannot purchase a 160 series number the way you would a standard SIM or VoIP number.

Eligibility Verification Documents for 160 Series Allocation

The DoT Press Release of 30 May 2024 (PRID 2022249) placed a positive obligation on TSPs to verify entity eligibility before assigning any 160 series number. In practice, your TSP will require the following documents during the application:

• Certificate of Incorporation or equivalent registration document establishing the entity’s legal existence
• Sectoral regulator licence or registration certificate (RBI licence, SEBI registration, IRDAI certificate of registration, or PFRDA authorisation, as applicable)
• PAN card of the entity
• Authorised signatory undertaking confirming that the 160 series number will be used strictly for service and transactional calls under TCCCPR, 2018
• Business description specifying the use case for each requested number (OTP delivery, EMI reminders, policy renewal alerts, etc.)

The undertaking is not a formality. Signing it creates a contractual obligation at the point of allocation. A single promotional call from the allocated 1601 number breaches that undertaking. It also independently triggers TCCCPR penalty provisions, regardless of whether a consumer complaint is lodged.

Number Capacity Planning Before Your 160 Series Application

Before you approach your TSP, conduct a concurrency analysis. Calculate the peak simultaneous outbound call volume across all use cases: OTP, collections, service alerts, and IVR inbound. Size your 160 series number pool accordingly. Moreover, plan for geographic or language-based segmentation if your IVR routes callers by region, because each segment may need a distinct number.

What this means for your compliance team is that the allocation request must follow a capacity plan, not a single-number request. A BFSI entity that acquires one 1601 number and routes all traffic through it will face call-quality degradation under load. Furthermore, it may need to reapply, which adds weeks to the migration timeline. Therefore, thorough capacity planning at this stage saves significant time later.

Step 2: SIP Trunk and PRI Configuration for 160 Series CLI Presentation

SIP trunk configuration is the most technically critical layer in the 160 series IVR and dialer setup. The core requirement is straightforward: the Caller Line Identification (CLI) on the receiving handset must be the actual allocated 1600 or 1601 number. No masking, no overlay, no virtual number sitting in front of the 1601 allocation is acceptable.

SIP Trunk Parameters for 1601 CLI Presentation in 160 Series Dialer Setup

When you configure the SIP trunk between your cloud dialer or on-premise PBX and the TSP’s network, set the following parameters explicitly. Many PBX systems default to internal extension values, so override each one at the trunk level, not only at the campaign level.

• From header: Set to the full 1601xxxxxxx number in E.164 format (e.g., +911601XXXXXXXX). Many PBX systems default to the internal extension or trunk DID. Override this at the trunk level.
• P-Asserted-Identity (PAI) header: Set to the same 1601 number. Indian TSPs use PAI for CLI verification at the network layer. Mismatches between the From header and PAI trigger anti-spoofing filters.
• Diversion header: Suppress or remove this header. An unexpected Diversion header causes the TSP’s anti-spoofing filter to block the call before it reaches the consumer.
• Codec selection: Use G.711 (a-law or u-law) as the standard. G.729 is acceptable but confirm with your TSP that transcoding is available end-to-end before deploying IVR flows with DTMF inputs.
• DTMF signalling: Select RFC 2833 (RTP Event) for IVR digit capture. In-band DTMF is unreliable over compressed codecs. Configure your SIP trunk and IVR platform to match on RFC 2833.

PRI Lines: When SIP Is Not an Option for Your 160 Series Setup

Some older on-premise PBX deployments use PRI (Primary Rate Interface) lines rather than SIP. PRI-based 160 series configuration follows the same CLI requirement, but implementation differs. Specifically, request your TSP to provision the 1601 number as the calling party number (CPN) on the PRI channel group. Additionally, confirm that your PBX passes the CPN from the PRI to all outbound calls without substituting its own internal extension or pilot number.

In my practice advising telecom-sector clients, several BFSI entities completed the TSP allocation and DLT registration steps correctly, only to discover at go-live that their legacy PBX was overriding the 1601 CLI with the PBX’s own pilot number. The fix is straightforward once someone identifies the issue, but the discovery typically adds two weeks to the project. Therefore, CLI verification should be item one on your pre-go-live checklist.

Step 3: DLT Platform Registration and 160 Series IVR Script Template Approval

DLT template registration for IVR scripts is the compliance step most BFSI IT teams underestimate in their 160 series IVR and dialer setup. The Telecom Commercial Communications Customer Preference Regulations, 2018 (TCCCPR) require every voice script to carry pre-registration as a content template on the Distributed Ledger Technology (DLT) platform. This obligation applies to every automated message, every agent introduction, and every IVR menu prompt used during a service or transactional call on a 1600/1601 number.

Principal Entity Registration on the DLT Platform

If your entity has not yet registered as a Principal Entity (PE) on the DLT platform, complete that step before template submission. The registration requires entity KYC documents, including PAN, GST certificate, and sectoral licence. Approval typically takes 3 to 7 business days. Notably, you register on one operator’s DLT platform and the registration syncs across all Indian TSPs automatically.

Which IVR Scripts Require DLT Template Registration in a 160 Series Setup

Every distinct voice script that plays during a 1600/1601 outbound call requires its own approved template. The following IVR components each need separate template registration as part of your 160 series IVR and dialer setup:

• IVR welcome message: The opening prompt identifying the entity and the call purpose
• OTP delivery scripts: Each distinct OTP announcement format, including different language versions
• EMI reminder scripts: Each variation such as first reminder, second reminder, and overdue notice
• Agent introduction scripts: The scripted introduction an agent delivers at call connection, if it includes regulatory disclosures required by the 2025 Second Amendment
• Voicemail drop scripts: If your dialer leaves pre-recorded messages, each message variant is a separate template
• Language variants: Hindi and Tamil versions of the same script are separate templates

Passing the Template ID in SIP Signalling for 160 Series Calls

The Template ID is not merely a registry record. Your dialer must pass it in the outbound call’s SIP signalling so the TSP’s network can validate the call against the approved template at origination. The mechanism varies by platform, so confirm the exact header name and format with your TSP before configuration.

• For SIP-based cloud dialers, pass the Template ID in a custom SIP header such as X-DLT-Template-ID or an equivalent field your TSP specifies.
• For API-driven outbound calling platforms, pass the Template ID as a parameter in the API call payload.
• Implementation varies between Airtel, Jio, Vi, and Smartping platforms, so obtain the exact specification from each TSP you use.

Calling with an unregistered template, an outdated template, or a blacklisted template is a violation regardless of whether the originating number is a valid 1600/1601 allocation. Therefore, a post-go-live script change, even a minor wording update, requires re-registration and template re-approval before the updated script goes live on the 1601 number. Most entities overlook this requirement and create compliance exposure after go-live.

Step 4: 160 Series Dialer Routing Segregation from 140 Traffic

Routing segregation is both a legal requirement and an architectural decision in every 160 series IVR and dialer setup. The same dialer instance cannot route promotional 140 traffic and transactional 1600 traffic through the same number pool. This boundary must be technical and enforced at the system level. Regulators and auditors have confirmed that a policy document without enforced routing logic does not constitute adequate compliance.

Technical Architecture for 160 Series and 140 Series Segregation

The following architecture implements compliant segregation in a cloud dialer environment. Apply each of these controls before you direct live traffic to any 160 series number.

• Separate SIP trunk groups: Configure one trunk group bound exclusively to the 1600/1601 number pool and a separate trunk group bound to the 140 number pool. Enforce campaign assignment to trunk group at the dialer platform level, not through agent discretion.
• Campaign-level number locking: Hard-code the trunk group for each outbound campaign. Transactional campaigns (OTP, EMI reminders, policy alerts) must lock to the 1601 trunk. Promotional campaigns must lock to the 140 trunk. System-level locking prevents accidental rerouting.
• IVR flow tagging: Tag every IVR flow with the number series it is authorised for. Flows tagged for 1601 should fail-safe to a compliance error rather than fall back to a 140 or 10-digit number if the 1601 trunk is unavailable.
• Outbound rule hierarchy in PBX: If you use an on-premise PBX with a cloud IVR overlay, configure outbound dial rules so that calls matching transactional campaign prefixes route only to the 1601 SIP trunk, with no fallback to other trunk groups.

Why Fail-Safe Matters More Than Failover in 160 Series Dialer Setup

Most dialer platforms default to failover routing. If the primary trunk is unavailable, the call routes to an alternate trunk. For 1601 transactional calls, this default creates a direct compliance risk. Specifically, if the 1601 trunk fails and the dialer falls back to a 10-digit number, that call becomes Unsolicited Commercial Communication from an Unregistered Telemarketer under TRAI’s Direction. Therefore, configure the 1601 trunk to fail-safe: if the trunk is unavailable, the call should queue or drop, not reroute to an alternative number class.

What this means for your IT team is a specific configuration change in your outbound routing policy, not only a network-level failover setting. Test the fail-safe scenario explicitly during pre-go-live testing, which Step 7 covers in detail.

Step 5: CRM and API Integration for 160 Series Outbound Calls

A technically correct 160 series IVR and dialer setup extends beyond the telephony layer. Your CRM integration must ensure that the correct Template ID passes for each call type and that the system checks each customer’s consent status before initiating a call.

Consent Check at the API Layer for 160 Series Calls

The TCCCPR Second Amendment of 12 February 2025 tightened consent rules significantly for 160 series IVR and dialer operations. Specifically, implicit consent for transactional or service calls is valid only for the duration of the underlying contract. Explicit consent lasts 7 days. A customer who opts out cannot receive another contact for 90 days on the same purpose. Consequently, your outbound dialer API must query the consent status in real time before each call attempt, not only at campaign load time.

Additionally, the 2025 Second Amendment requires auto-dialer disclosure at the start of each call. This disclosure must carry its own registered DLT template. Therefore, your IVR flow builder must insert the auto-dialer disclosure as the first prompt in any outbound IVR call, before the substantive message content.

CRM Mapping to Template IDs in Your 160 Series Environment

Each use-case type in your CRM (OTP, EMI reminder, policy renewal, collection call, service alert) must map to a specific DLT Template ID. Store this mapping in the CRM or a middleware layer, not only in the dialer configuration. The mapping table serves two purposes: it ensures the correct Template ID passes in SIP signalling for each call type, and it provides the audit trail that TCCCPR and the RBI Fair Practices Code require.

Compatible CRM platforms for this 160 series integration include HubSpot, Zoho CRM, Salesforce, and LeadSquared. FreJun provides native connectors to all four, with Template ID mapping handled within the platform rather than requiring custom development on your side.

Transactional Call Window Enforcement in 160 Series Dialer Operations

The 2025 Second Amendment defines transactional content as messages triggered within 30 minutes of a customer-initiated transaction. Anything beyond that window is service content and requires a different consent basis. Therefore, your CRM integration must pass a timestamp to the dialer for each transactional call trigger. The dialer then checks whether the trigger timestamp falls within the 30-minute window before initiating the call. Calls outside the window should automatically route to a service-template flow with the appropriate consent check.

Step 6: CDR Logging, Call Recording, and Audit Trail for 160 Series Calls

Record-keeping is a mandatory compliance obligation in every 160 series IVR and dialer setup, not a best practice. Every call on a 1600/1601 number must generate a complete Call Detail Record (CDR) that is retained, auditable, and cross-referenced to the DLT Template ID used for that call. Furthermore, RBI, SEBI, IRDAI, and PFRDA each impose sector-specific retention requirements that typically exceed the minimum under TSP licence conditions.

Minimum CDR Fields for 160 Series Compliance

Each CDR entry for a 1600/1601 outbound call must include at minimum the following fields. Your platform must populate every field automatically, without relying on manual entry.

• Originating number: The exact 1601xxxxxxx number from which the call was placed
• Destination number: The consumer’s number in full
• Call timestamp: Date and time in IST with seconds precision
• Call duration: In seconds
• Call disposition: Connected, unanswered, voicemail, busy, or failed
• DLT Template ID: The specific template identifier used for that call
• Consent basis: Whether the call used implicit transactional consent, explicit consent, or a legitimate-use basis, with the consent record ID where applicable
• Campaign or use-case tag: OTP, EMI, policy renewal, service alert, etc.
• Agent ID: For human-agent calls, the agent identifier

Data Localisation for BFSI Call Records in the 160 Series Framework

For BFSI entities, customer call data sits at the intersection of the Digital Personal Data Protection Act, 2023 (DPDP Act) and the RBI’s Storage of Payment System Data circular of 6 April 2018. Call recordings, CDRs, and voicemail data of Indian BFSI customers must reside on servers physically located within India. Moreover, the RBI IT Outsourcing Master Direction of 10 April 2023 (RBI Notification) requires any vendor handling this data to provide audit rights, business continuity provisions, and documented data protection commitments.

What this means for your IT team is that a cloud telephony vendor using overseas infrastructure does not satisfy the data localisation requirement for your 160 series setup. Before selecting any cloud dialer or IVR platform for 1601 number calls, confirm that CDR and call recording storage sits on India-located servers.

Step 7: Pre-Go-Live Testing for 160 Series IVR Compliance Validation

Pre-go-live testing for a 160 series IVR migration differs from standard telephony UAT because it must validate compliance requirements, not only functional requirements. The following test scenarios are non-negotiable before any 1601 number carries live traffic.

CLI Verification Test for Your 160 Series Number

Place a test call from the configured 1601 number to multiple handsets across different operators: Airtel, Jio, Vi, and BSNL. Verify that the number on each receiving handset is the exact 1601xxxxxxx number. No masking, no substitution, and no internal extension should appear. Record the displayed CLI from each test call in your go-live checklist.

Template ID Validation Test for 160 Series DLT Compliance

For each IVR flow and each campaign type, verify that the correct Template ID passes in the SIP signalling and that the network does not block the call. A blocked call at this stage indicates either a template approval issue or a signalling configuration error. Resolve all blocked calls before go-live. Additionally, test a deliberately incorrect Template ID to confirm that the system blocks the call rather than allowing it through with no template reference.

Routing Segregation Test

Attempt to manually override the campaign trunk assignment for a transactional campaign. Confirm that the system either blocks the override or prevents the call from initiating. This test validates that routing segregation operates at the platform level, not only in policy documents. Document the test result and the system response as part of your compliance audit trail.

Fail-Safe Test for Trunk Unavailability

Simulate a 1601 trunk outage by temporarily disabling the trunk configuration. Then initiate a transactional call from that campaign. Verify that the call fails safely, meaning it queues or drops rather than routing to a 140 or 10-digit number. The system should log this automatically in the CDR as a failed call with a trunk-unavailable disposition, not as a connected call on an alternate number.

CDR Completeness Test for 160 Series Call Records

Make a set of test calls across all campaign types and immediately retrieve the CDR entries. Verify that the Template ID field is populated for each record and that the consent basis field matches the configured campaign type. Confirm that call recordings are accessible and that storage sits on India-located infrastructure. Incomplete CDR fields at this stage indicate a configuration gap that you must resolve before live traffic flows.

BPO and Recovery Agent Technical Configuration for the 160 Series

If your entity uses a BPO or recovery agency for outbound calls, the technical configuration requirements of the 160 series IVR and dialer setup apply equally to the BPO’s infrastructure. Critically, the 1601 number belongs to the Principal Entity (the bank, NBFC, or insurer), not the BPO. Therefore, the BPO must make calls through the Principal Entity’s allocated 1601 number, not its own number pool.

SIP Trunk Sub-Allocation to BPOs for 160 Series Calling

The technical mechanism for enabling a BPO to use the Principal Entity’s 1601 number is SIP trunk sub-allocation or a SIP trunking relay arrangement. Specifically, the Principal Entity’s 1601 SIP trunk extends via SIP routing or a cloud dialer API to the BPO’s dialer platform. The BPO’s platform initiates calls through the Principal Entity’s trunk and presents the 1601 CLI. The BPO does not own or operate a separate 1601 number under this arrangement.

This arrangement has a critical implication. The Principal Entity bears vicarious liability for every call the BPO makes on its 1601 trunk. Under TCCCPR, the RBI Fair Practices Code, and the RBI Master Direction on Outsourcing of IT Services (10 April 2023), the Principal Entity cannot outsource its compliance obligations. Furthermore, the BPO must carry Telemarketer (TM) registration on the DLT platform and connect to the Principal Entity’s PE registration through a PE-TM chain.

PE-TM Binding on the DLT Platform

The PE-TM binding is the DLT-level link between the Principal Entity’s registration and the BPO’s Telemarketer registration. Without this binding, calls originating from the BPO’s dialer using the PE’s 1601 trunk will face rejection at the network layer or classification as unauthorised commercial communication. Set up the PE-TM chain on the DLT platform before the BPO begins live calling. Confirm the binding by running a test call and verifying that the CDR shows the correct PE registration reference.

How FreJun Simplifies the 160 Series IVR and Dialer Setup

FreJun is India’s cloud telephony platform for BFSI compliance use cases. The platform handles each of the seven technical setup steps in your 160 series IVR and dialer setup within a single managed environment. This approach reduces the typical 4-to-8-week migration to a 48-hour go-live for most entities.

• TSP application support: FreJun assists with the eligibility documentation and undertaking that TSPs require for 1601 number allocation.
• Pre-configured SIP trunk for 160 series: FreJun’s platform presents the 1601 CLI correctly by default. The From header, PAI header, and DTMF signalling are pre-configured for Indian TSP requirements. No manual SIP configuration is necessary on the entity’s side.
• DLT template management: FreJun manages the DLT PE registration process and handles template submission, approval tracking, and Template ID mapping within the platform. Script updates trigger an automatic re-registration workflow rather than requiring a manual DLT portal update.
• Segregated routing architecture: Promotional and transactional traffic route through physically separate trunk groups in the FreJun platform. Fail-safe, not failover, is the default for 1601 trunks.
• CRM connectors with Template ID mapping: Native connectors for HubSpot, Zoho, Salesforce, and LeadSquared include a Template ID mapping layer and a consent status check at the API call level.
• India-located CDR and recording storage: All call data resides on servers located within India, satisfying the RBI data localisation requirement for 160 series operations.
• Pre-go-live compliance validation: FreJun runs the full seven-step testing protocol as part of onboarding, including CLI verification, Template ID validation, and fail-safe testing specific to your 160 series configuration.

The clients I work with in the telecom-compliance space spend the longest time on DLT template registration, typically 2 to 3 weeks for first-time registrants managing the process manually. FreJun’s managed DLT workflow cuts that to 3 to 5 business days because the platform handles submission, tracks approval status, and flags rejections automatically. The time saving for your 160 series setup is substantial.

Talk to FreJun’s Legal Team

Frequently Asked Questions

What is the difference between the 160 series and 140 series for IVR and dialer use?

The 140xxxxxxx series covers only promotional and telemarketing calls. The 160xxxxxxx series is reserved exclusively for service and transactional calls by verified Principal Entities. BFSI entities that use a 140 number for OTP delivery, EMI reminders, or any service call are non-compliant after the TRAI Direction of 19 November 2025 (PRID 2191647). These two series are not interchangeable. Source: DoT, 30 May 2024, PRID 2022249.

What penalty applies when a BFSI entity uses its dialer on a 10-digit number after the 160 series migration deadline?

TRAI classifies calls from a 10-digit number that should use a 1601 allocation as Unsolicited Commercial Communication from an Unregistered Telemarketer. Financial penalties under TCCCPR are Rs 2,00,000 for the first violation, Rs 5,00,000 for the second, and Rs 10,00,000 for each subsequent violation. The blacklist trigger is 5 complaints in any rolling 10-day period, and the maximum blacklist extends to 1 year across all telecom resources and all TSPs.

How does an entity apply for a 1601 number and how long does the 160 series setup process take?

The entity applies directly to its Telecom Service Provider with eligibility documents: sectoral regulator licence, PAN, Certificate of Incorporation, and a signed undertaking on use restrictions. The TSP then conducts eligibility verification before allocation. Processing time varies by TSP and ranges from 5 to 15 business days. Completing a capacity plan before application avoids reapplication delays and speeds up your overall 160 series IVR and dialer setup timeline.

Does every IVR script need a separate DLT template in a 160 series setup, or does one template cover all flows?

Each distinct script content variant requires its own DLT template registration. One template does not cover multiple scripts. A welcome message, an OTP announcement, an EMI reminder, and a voicemail drop are each separate templates. Language variants of the same script also require separate templates. Template approval takes 1 to 5 business days per submission on most DLT platforms. Plan for this lead time in your 160 series project schedule.

Can a BPO or recovery agent use its own SIP infrastructure for 1601 calls?

No. The 1601 number belongs to the Principal Entity (bank, NBFC, or insurer), not the BPO. The BPO must make calls through the Principal Entity’s allocated 1601 trunk via a SIP sub-allocation or API relay arrangement. The BPO must also carry Telemarketer registration on the DLT platform and connect to the Principal Entity’s PE registration via a PE-TM chain. The Principal Entity bears vicarious liability for all calls the BPO makes on its 1601 number.

What happens if the 1601 SIP trunk goes down during live 160 series operations?

Configure the 1601 trunk to fail-safe, not fail-over. If the trunk is unavailable, transactional calls should queue or drop rather than route to a 140 or 10-digit fallback number. Rerouting to any other number class during a trunk outage constitutes a direct compliance violation under the TRAI Direction of 19 November 2025. Test this fail-safe configuration explicitly before go-live and verify it again after any infrastructure change.

What are the data localisation requirements for CDR and call recording storage in a 160 series setup?

For BFSI entities, call recordings and CDRs involving Indian customer data must reside on servers physically located within India. This obligation flows from the RBI’s Storage of Payment System Data circular (6 April 2018) and the Digital Personal Data Protection Act, 2023. Cloud telephony vendors that use overseas infrastructure do not satisfy this requirement. Confirm India-based storage with your vendor before signing any SaaS agreement for outbound calling infrastructure supporting your 160 series setup.

Key Takeaways

• The 160 series IVR and dialer setup has five non-negotiable technical layers: TSP allocation, SIP CLI configuration, DLT template registration, routing segregation, and CDR logging with Template ID mapping.
• CLI masking of a 1601 number violates Section 42 of the Telecommunications Act, 2023. This is a criminal offence, not merely a regulatory infraction.
• Every IVR script variant, including language versions and voicemail drops, requires its own DLT template approval before going live on a 1601 number as part of your 160 series setup.
• Routing segregation between 140 promotional and 1600 transactional traffic must operate at the technical system level. A policy document alone does not satisfy the requirement.
• BPOs and recovery agents must operate through the Principal Entity’s 1601 trunk via a PE-TM DLT binding. The Principal Entity bears vicarious liability for all agent calls on its allocation.
• CDR records must reside on India-located servers and retain the DLT Template ID, consent basis, and full call metadata for each 160 series transactional call.
• FreJun’s pre-configured 160 series IVR and dialer environment covers all seven technical setup steps and reduces a standard 4-to-8-week migration to a 48-hour go-live for most BFSI entities.

Compliance Disclaimer

Disclaimer: This article is published for informational purposes only and represents FreJun’s understanding of the relevant legal and regulatory position based on its own independent research and interpretation of publicly available materials. It should not be construed as legal advice, legal opinion, or regulatory guidance. Readers are encouraged to seek independent legal counsel or consult the appropriate regulatory authorities before taking any action based on the information contained herein. While reasonable efforts have been made to ensure the accuracy and completeness of the information presented, laws, regulations, interpretations, and enforcement positions may evolve or vary based on specific facts and circumstances. FreJun does not warrant that the contents are free from inaccuracies, omissions, or inadvertent errors and shall not be responsible or liable for any misinformation, inaccuracies, or reliance placed upon the contents of this article, whether published knowingly or unknowingly.

References and Sources

• DoT Press Release, 30 May 2024 (PRID 2022249) — pib.gov.in
• TRAI Direction, 19 Nov 2025 (PRID 2191647) — pib.gov.in
• TRAI Direction, 16 Dec 2025 (PRID 2205350) — pib.gov.in
• TCCCPR Second Amendment, 12 Feb 2025 — trai.gov.in (PDF)
• RBI Master Direction on Outsourcing of IT Services, 10 April 2023 — rbi.org.in
• DPDP Act, 2023 — meity.gov.in
• Mondaq Analysis — 1600 Series and DPDP Crossover — mondaq.com
• FreJun BFSI Compliance Guide — frejun.com/blog/bfsi-communication-compliance-guide-2026
• FreJun — TCCCPR 2018 Compliance Guide — frejun.com/blog/tcccpr-2018-compliance-guide
• FreJun — 160 Series vs 140 Series — frejun.com/blog/160-series-vs-140-series