Compliance

Gooclaim OS is built for India’s insurance regulatory regime — from IRDAI’s 1-hour / 3-hour cashless mandate to the DPDP Act 2023. Compliance is wired into the platform’s architecture, not bolted on as policy. This page maps each obligation to the control that enforces it.

1. Regulatory coverage

Gooclaim OS supports Customers (insurers and TPAs) in meeting obligations under:

• IRDAI Master Circular on Health Insurance Business (29 May 2024) — the 1-hour cashless authorisation and 3-hour discharge mandate.
• IRDAI Master Circular on Protection of Policyholders’ Interests (5 Sep 2024) — 15 days to settle a claim from its submission, interest at bank rate + 2% a year from the day of intimation when it is settled late, and no claim closed for want of documents.
• IRDAI records rules — claim records, correspondence included, kept under the Customer’s own board-approved retention policy, which those rules require it to hold. Gooclaim OS defaults to ten years.
• IRDAI Internal Ombudsman Guidelines 2025 — mandatory internal grievance handling with audit-grade records.
• Digital Personal Data Protection Act, 2023 (DPDP) — lawful basis, consent, processor obligations, data principal rights.
• Information Technology Act, 2000 — Sections 43A and 72A — reasonable security practices and protection of personal information.

2. The control map

Each regulatory obligation is enforced by a specific Gooclaim OS control. None are advisory — they are platform-enforced.

2.1 Consent gate (DPDP, IT Act)

Every conversation begins with an explicit consent check. No claim detail is shared in a conversation without a recorded CONSENT_GIVEN state against the claimant. The one exception is a notice the insurer or TPA is obliged by IRDAI to send — such as a request for documents a claim still needs — which goes only to the contact registered on the policy, carries claim information only, and is never sent to anyone who refused or withdrew consent. Consent withdrawal is honored within one business day and immutably logged.

2.2 Policy Gate (IRDAI, IT Act, brand-safety)

Every outbound message passes a 4-tier safety check before delivery — exact-template match, semantic safety check, personal-data redaction, and source verification. Free text never reaches a customer.

2.3 Audit ledger (IRDAI, Ombudsman, DPDP)

Every automated decision, every outbound message, every consent change, every policy-gate outcome is written to an append-only, SHA-256-chained audit ledger. Events that belong to a claim are retained for ten years, operational events for 90 days (see § 4), and both can be exported on demand.

2.4 Per-tenant isolation (DPDP, IT Act)

Multi-tenant data is isolated at every layer — credentials, knowledge sources, audit events, dashboards. One tenant’s data is never accessible to another, even by Gooclaim engineers under normal operations.

2.5 Personal data hygiene (IT Act, DPDP)

Phone numbers, names, claim identifiers and other identifying fields are masked or hashed in internal logs — raw values are never written to log lines. Aadhaar, PAN, card and bank numbers are masked before a conversation is stored. Every language-model call goes through our own model gateway, and no Customer or claimant data is used to train a model.

2.6 Operational mode (IRDAI, business continuity)

Every workflow can be set to OPERATIONAL, RESTRICTED or SUSPENDED per tenant. The kill-switch is intended for incident response — for example, pausing outbound during a CMS outage — and is itself an audited action.

2.7 Templates-only output (IRDAI, brand-safety)

Outbound to claimants is restricted to pre-approved, versioned templates per channel and language, each approved by the Customer before it is enabled.

2.8 IRDAI clocks and turnaround reporting

Every claim carries its IRDAI clock — 1 hour for cashless authorisation, 3 hours for discharge, 15 days to settle — with the interest at stake when it runs late, shown to the Customer’s team as the claim moves. Complaints carry their own clock. The quarterly NL-48 turnaround report is built from the same record, and a filed copy is frozen with its SHA-256.

3. Security architecture

• Encryption in transit (TLS 1.2+) and at rest.
• Short-lived signed tokens for service-to-service authentication.
• Per-tenant credential vaults, encrypted at the field level.
• Zero-trust between internal services — no implicit network trust.
• Static analysis, dependency and secret scanning in the release process.
• Responsible-disclosure channel at security@gooclaim.com.

4. Data residency and retention

Gooclaim OS runs on Amazon Web Services. The hosting region is agreed with each Customer in its contract and can be an India region. AI models are reached only through our own model gateway; their providers are listed in section 5.

Retention is not one period. It turns on whether something is part of a claim record:

• Ten years, from the last activity on the claim — claim documents, a conversation that belongs to a claim or complaint, and the audit ledger events for that claim. IRDAI requires a Customer to hold a board-approved records and archival policy rather than fixing a period itself, so ten years is our default: a Customer may set it higher, up to thirty years, and cannot set it lower.
• 90 days — conversation content that belongs to no claim or complaint, expired or used upload links, and operational ledger events that carry no compliance obligation.
• 30 days — the bytes of a file that was refused or held and never became a claim document.

A legal hold — a court case, a regulator’s order — suspends every deletion until the Customer lifts it. Beyond these periods, data is purged or returned per the engagement’s data-processing terms.

5. Sub-processors

Gooclaim OS uses a small set of sub-processors: Amazon Web Services (cloud hosting, storage, encryption keys and email delivery), Meta (WhatsApp delivery), and Anthropic, OpenAI and Mistral AI (AI models, reached only through our own model gateway). Each sub-processor is bound by a data-processing agreement and is reviewed annually. A live list is available to Customers under the MSA.

6. Incident response

We maintain an incident-response playbook covering detection, containment, eradication, recovery and post-incident review. Security incidents involving personal data are reported to the Data Fiduciary (the engaging insurer or TPA) without delay, so that it can inform the people affected and the Data Protection Board of India within the timelines the DPDP Rules set, and as the MSA requires. The current playbook version is available to Customers under NDA.

7. Responsible AI posture

• Large language models are used for internal reasoning, not for free-text responses to claimants.
• The Policy Gate validates every outbound for brand-safety, regulatory and factual grounding before delivery.
• We never use Customer or claimant data to train external, third-party models.
• Model providers are kept behind an internal model gateway so providers can be swapped without changing application code.
• Every model invocation that influences a customer-visible outcome is written to the audit ledger.

8. Customer responsibilities

Compliance is a shared model. Gooclaim OS provides platform-level controls; the engaging Customer remains responsible for:

• Maintaining a lawful basis under DPDP for each claimant interaction.
• Approving templates before they are enabled in production.
• Responding to claimant grievances and regulator requests within applicable timelines.
• Keeping API credentials and operator accounts secure.

9. Contact

• Compliance questions → contact@gooclaim.com
• Security disclosures → security@gooclaim.com
• Grievance officer (DPDP) → contact@gooclaim.com · acknowledged within 3 business days, answered within the time the DPDP Rules allow
• Read alongside this page — Privacy Notice and Terms of Service. The three are meant to be read together.