Policy, premium and bonus data behind the My LIC login

Behind the OTP login, a My LIC account exposes policy status — plan, term, sum assured, date of commencement and first unpaid premium — alongside the year-by-year premium-paid statement, the accrued bonus position, any loan taken against the policy, and claim status. One login can also list policies held for a spouse and children, not just the holder. That is the dataset a third party usually wants out of LIC: structured, per-policy, and tied to a registered mobile number. This brief covers what My LIC holds, the authorized way to reach it, and what we hand over at the end.

The bottom line: this is a regulated-data app where the cleanest long-term reach depends on who is asking. A receiver that is itself IRDAI- or RBI-regulated can take standardized insurance data over the Account Aggregator network. Everyone else, and any app-only field the network does not yet carry, is served by authorized protocol analysis of My LIC under the policyholder's own consent. We build whichever of those fits your situation and wrap it in a documented, runnable interface.

What a policyholder's account holds

Each row below is a surface My LIC actually presents to a signed-in user, mapped to where it originates and what it is good for downstream.

Authorized routes into the data

Three routes apply here. They are not mutually exclusive; a real build often combines them.

Account Aggregator (RBI), consent-based

India's Account Aggregator network moves financial data between regulated institutions through a licensed, data-blind NBFC-AA that holds the consent. Insurance data — policy types, premium schedules, claim history, coverage — flows on it when the insurer or an insurance repository is enrolled as a Financial Information Provider and the receiver is a Financial Information User regulated by IRDAI, RBI, SEBI or PFRDA. Reach is standardized and the consent is auditable and revocable. Effort sits in the FIU onboarding, which we route and document with you. Durability is high because the schema and the consent rails are regulated, not scraped.

Authorized protocol analysis under policyholder consent

This reads what the app itself shows once a consenting policyholder is signed in: the full status, bonus, loan, statement, claim and notification surfaces, including fields the Account Aggregator stream does not carry. We reconstruct the OTP/token login, capture the request and response shapes, and turn them into a stable interface. Effort is moderate. Durability is medium, since the front end can change — which is why maintenance is part of the engagement, not an afterthought.

Consented native export

My LIC and the LIC customer portal already let a policyholder download a premium-paid statement PDF, view the policy-bond schedule and read a policy-status snapshot. Under the holder's login we automate that retrieval and parse the documents. Low effort, useful where a surface is simply easier to read as a downloaded statement than as live traffic. We use it to fill gaps rather than as the whole answer.

Which one we reach for: if you are an IRDAI- or RBI-regulated entity, the Account Aggregator path is worth the onboarding because the data arrives standardized and the consent trail is clean. If you are not, we start with authorized protocol analysis under the policyholder's consent, since it reaches every screen the app renders, and use consented export to pick up the premium-paid PDFs where parsing a document beats reconstructing a call.

What lands at the end of the build

You get a working integration for My LIC, not a report. Tied to the surfaces above, that means:

• An OpenAPI/Swagger specification covering the policy-list, status, premium-paid-statement, bonus, loan and claim-status calls.
• A protocol and auth-flow report: the User-ID / OTP login, token issuance and refresh, and session handling as observed during the build.
• Runnable source for the key endpoints in Python or Node.js — authenticate, list policies, pull a statement by financial year, read bonus and loan position.
• A normalized schema so a household's policies, premiums and loans land in one consistent shape regardless of plan type.
• Automated tests against representative responses, plus interface documentation an engineer can hand to the next person.
• Consent and data-retention guidance written for the Account Aggregator regime and the DPDP Act.

Signing in and reading a statement

Illustrative shape only; exact field names and the token mechanism are confirmed during the build against a consenting account.

# 1) Start login with the registered identifier
POST /auth/otp/request
  { "userId": "POLICYHOLDER_ID" }      # or registeredMobile
  -> { "txnId": "…", "otpChannel": "sms" }

# 2) Exchange the one-time password for a session token
POST /auth/otp/verify
  { "txnId": "…", "otp": "######" }
  -> { "accessToken": "…", "expiresIn": 900, "refreshToken": "…" }

# 3) List policies on the account (self, spouse, children)
GET /policies        Authorization: Bearer <accessToken>
  -> [ { "policyNo": "…", "plan": "…", "term": 21,
         "sumAssured": 500000, "lifeAssured": "SELF",
         "status": "IN_FORCE", "firstUnpaidPremium": "2026-09-28" } ]

# 4) Pull the premium-paid statement for one financial year
GET /policies/{policyNo}/premium-statement?fy=2025-26
  -> { "policyNo": "…", "fy": "2025-26",
       "entries": [ { "date": "…", "amount": 0, "mode": "UPI",
                      "receiptId": "…" } ],
       "bonusAccrued": 0,           # projection, payable at settlement
       "loanOutstanding": 0 }

# handle: token refresh on 401, OTP re-request on session expiry,
# and FY values absent before the policy's first premium year

Where teams plug this in

• A wealth or net-worth app folding a client's LIC policies in beside bank and mutual-fund holdings.
• A lender pulling outstanding policy-loan and surrender-value figures during underwriting.
• A tax or accounting tool importing annual premium-paid statements for Section 80C filing.
• A household-finance app surfacing upcoming premium dues and lapse risk across every family policy in one view.

Consent, the Account Aggregator regime and IRDAI

For LIC data specifically, two things govern the work. The Account Aggregator network sets the regulated, consent-first path: nothing moves without the policyholder's explicit, purpose-bound and time-bound consent, and the holder can revoke it at any point. The Insurance Regulatory and Development Authority of India (IRDAI) regulates the insurer side and any insurance-distribution use of the data. Across both, India's Digital Personal Data Protection Act, 2023 is the personal-data baseline.

How we operate inside that: access is authorized, consent records are kept, and pulls are scoped to the fields a use case actually needs. Bonus and loan figures are read as point-in-time values, not exported as anything more. We work under NDA where a client needs it, and every retrieval runs against a consenting account or a sandbox arranged with you during onboarding.

Build notes specific to My LIC

Three things shape an LIC integration, and we account for each rather than handing them to you as conditions.

• Household policies. One account can carry policies for self, spouse and children. We model the policy list as a per-life collection so each record maps to the correct life-assured, instead of being flattened onto the logged-in holder.
• OTP and the registered mobile. Sign-in leans on a one-time password to the registered number. We design the session and token refresh around that and plan for OTP delivery, so a scheduled sync re-authenticates cleanly instead of stalling.
• Bonus is a projection. The accrued-bonus figure is payable only at maturity, claim or final settlement. We tag it as a projection in the normalized schema so a consuming system never books it as a withdrawable balance.

The app runs on LIC's DIVE platform, so its front end will move over time. We keep a check that flags when responses change shape, and the integration is updated before it breaks rather than after.

Screens from the app

Store screenshots, for reference to the surfaces named above.

How this brief was put together

Checked in June 2026 against LIC's own customer-portal documentation for the policy-status, bonus, loan and premium-paid-statement surfaces, the Play Store and App Store listings for the app's scope, the government press release announcing the My LIC launch, and the Department of Financial Services material on the Account Aggregator framework for the regulated route. Primary references:

• PIB — LIC launches MyLIC and Super Sales Saathi
• LIC — policy status, bonus, loan and statement surfaces
• LIC customer portal services
• Dept of Financial Services — Account Aggregator framework

Reviewed 2026-06-26 by the OpenBanking Studio integration desk.

Where My LIC sits among Indian insurance apps

The same integration approach travels across the category, which widens what a unified servicing layer can cover:

• SBI Life Smart Care — self-service for SBI Life policyholders: premium payment, policy documents and application tracking.
• HDFC Life Insurance App — in-app buying, policy tracking, renewals, and fund switch / premium redirection for unit-linked plans.
• Tata AIA Life Insurance — policy detail views and policy-related self-servicing transactions.
• ICICI Prudential Life — servicing, premium payment and fund values for ICICI Pru policyholders.
• Max Life Insurance — policy management, premium reminders and renewals.
• Bajaj Allianz Life — policy details, fund statements and servicing requests.
• Kotak Life — policy and premium servicing for Kotak Mahindra Life customers.
• Policybazaar — aggregator holding purchased-policy details, premium dates and coverage across insurers.
• SBI Buddy — wallet that can link a life policy for premium payment and tracking.

Questions integrators ask about My LIC

Does a My LIC account cover an entire family's policies?

Yes. The account can surface policies of self, spouse and children, the way LIC's customer servicing already groups them. We model each policy against the correct life-assured rather than flattening everything onto one holder.

Is the accrued-bonus figure a balance that can be withdrawn?

No. The bonus shown accumulates over the policy term and is payable at final settlement, maturity or claim, not on demand. We tag it as a projection so downstream code does not treat it as a realizable balance.

Can LIC policy data move through the Account Aggregator network?

The Account Aggregator regime carries insurance data such as policy types, premium schedules, claim history and coverage when the insurer or an insurance repository is onboarded as a Financial Information Provider and the receiver is an FIU regulated by IRDAI or another financial regulator. Where that path is not available for a given surface, we use authorized protocol analysis of the app under the policyholder's consent.

How is the OTP login handled in an automated pull?

My LIC signs in by User ID or by a one-time password sent to the registered mobile number. We build the session and token refresh around that flow and account for OTP delivery to the registered number, so a scheduled sync re-authenticates cleanly instead of failing silently.

One way to start the work: tell us the app name and what you want out of its data, and we map the route. Two delivery models cover it — we write the runnable API source plus its OpenAPI spec, tests and interface docs and you pay from $300 after delivery, once it works the way you need; or you call our hosted endpoints and pay per call with nothing upfront. Either way the cycle is one to two weeks. Start at /contact.html.