What an ISNP is and why a website alone will not do
An intermediary that wants to sell or service insurance online in India cannot simply launch a website and take payments. The activity sits inside a defined regulatory channel called the Insurance Self-Network Platform (ISNP). IRDAI issued the Guidelines on Insurance e-commerce dated 9 March 2017, which set out how permission is granted to establish an ISNP for insurance e-commerce in India.
The distinction is the whole point. A marketing site that generates leads is one thing; a platform on which a customer discovers, buys and services an insurance policy is regulated infrastructure that needs IRDAI's permission to operate. For a commercial broker or insurer planning digital placement, the ISNP framework is the gate every online-selling ambition has to pass through.
This guide treats the ISNP as an operations build, not a legal abstraction. The questions that follow are the ones a project team actually has to answer: how long does permission take, what security must the platform hold, what must happen after a policy sells, and how must money move.
The permission timeline and what IRDAI is assessing
Standing up an ISNP begins with an application to IRDAI. The regulator endeavours to decide on an ISNP application within 60 days from submission of all documents. The phrase that matters is all documents: the clock the applicant cares about starts when the file is complete, so an incomplete submission simply defers the start of the 60-day window.
That makes document readiness the real determinant of timeline. A project team that assembles the security review, the platform design, the policies and the supporting material before applying gives itself the cleanest path to a decision inside the window. One that applies early with gaps invites back-and-forth that pushes the effective decision date out.
The security review and ISMS obligation
Security is not an optional layer on an ISNP; it is a standing condition of running one. The guidelines require that an ISNP's controls, systems and safeguards be reviewed at least once a year by a certified information-system auditor (CISA) or a CERT-In empanelled expert. This is a recurring obligation, not a one-time certification at launch.
Alongside the audit, the applicant must maintain security standards equivalent to a recognised information-security management system. In practice that means holding an ISO or ISMS equivalent standard for the platform, so the audit has a defined control framework to test against.
For the project team, this reshapes the build. Security architecture, access controls, data protection and an auditable ISMS have to be designed in from the start, because they will be examined before permission and re-examined every year after. Retrofitting them after launch is both harder and a compliance risk.
What must happen after a policy sells: e-insurance accounts and payment controls
Once the platform is live and a customer buys, two operational rules govern the immediate aftermath, and both are concrete enough to design into the workflow.
The first is the e-insurance account. An e-insurance account must be created within 15 days of selling a policy on the ISNP. This is a hard timeline, so the platform's post-sale process has to trigger account creation automatically and track the 15-day clock per policy, rather than leaving it to manual follow-up that can slip.
The second is how money moves. Premium on an ISNP must be paid via card, net banking or e-wallet through a payment gateway. Cash and off-platform settlement are not the model; the digital channel is matched by digital, gateway-routed payment, which keeps the premium flow auditable and inside the controls the platform is built to maintain.
Building these into the workflow
A workable ISNP post-sale flow does three things in sequence: it confirms the gateway-routed premium payment, it issues the policy, and it triggers e-insurance account creation with a 15-day deadline tracked to completion. Designing these as automated steps rather than manual tasks is what keeps a high-volume platform compliant when sales scale up.
Uniform pricing and an ISNP readiness checklist
An ISNP does not let an intermediary run a different price online than off it. The channel is a delivery mechanism, and the discipline that the same product carries the same price regardless of channel keeps the platform from becoming a pricing arbitrage. For a commercial intermediary, the practical effect is that the online platform extends reach and efficiency without reopening pricing, which keeps the digital channel aligned with the rest of the book.
Pulling the operational requirements together, a readiness checklist for launching an ISNP runs as follows:
- Assemble the full application before filing, so IRDAI's 60-day decision window starts at a complete submission.
- Design security in from the start, hold an ISO or ISMS-equivalent standard, and schedule the annual CISA or CERT-In review as a recurring commitment.
- Automate the post-sale flow so e-insurance account creation is triggered and tracked within 15 days of each sale.
- Route every premium through a payment gateway via card, net banking or e-wallet, with no off-platform settlement.
- Hold pricing uniform across channels so the platform extends reach without creating arbitrage.
Underneath all of this sits the product itself. An online platform that sells commercial cover still has to present accurate wordings, terms and conditions, and an intermediary placing complex commercial risks digitally needs the underlying wording detail at hand to do that well.
Sarvada gives commercial insurance brokers structured, searchable access to insurer policy wordings and the intelligence around them, so a digital placement platform is built on accurate, current wording detail rather than static product copy. Request Access to ground your digital placement operations in real policy wordings.
