Moving an LIC agent's book out of Perfect Agent Plus into your own systems

An LIC agent's whole book sits inside Perfect Agent Plus — client names keyed to policy numbers, policy status, premium-due dates, and where the agent stands against club targets. PS Soft built it to work offline, writing that data straight onto the phone so an agent can answer a customer without a signal, per the company's own product page. For a team that wants those records flowing into a CRM, a renewals engine, or a commission ledger, the job is to build a client library that ingests the book once and then keeps it current — that ingestion layer is what this page is about.

The dependable basis for reading the data is the policyholder's and the agent's own authorization. India already has a consent-based rail for exactly this kind of insurance data, and a second authorized interface path fills the servicing gaps it does not yet cover. Both are described below, with the one we would lead on.

What Perfect Agent Plus actually holds

Each row maps a domain to where it surfaces in the app, how fine-grained it is, and what an integrator does with it. These reflect LIC agent workflows, not a generic checklist.

The authorized ways in

Two routes carry this data well; a third is a fallback. We arrange the access — consent artefacts, a sponsor sandbox, or a consenting agent account — with you during onboarding, so none of this is something you have to line up before we start.

Route A — Account Aggregator (Life Insurance FI)

India's Account Aggregator network is consent-first and now carries insurance. Sahamati's FI-type catalogue lists a Life Insurance financial-information type as active and live (v1.0.0, provided by life insurers), alongside a General Insurance type, with two older generic insurance types since withdrawn. The technical contract — request protocols, data schema, security — is published by ReBIT, RBI's technology subsidiary. Reachable here: the structured policy record and schedule, with the policyholder's consent. Durable, because it is a regulated standard rather than a private surface. This is the route we would lead on.

Route B — authorized interface integration

Servicing detail the AA feed does not yet expose — loan against policy, surrender value, revival eligibility — is read through the agent's own authorized portal session and folded into the same record. We analyse the request/response and token flow, then implement it as code. More moving parts than Route A, and it tracks the portal, so we schedule a periodic re-check and a changed field gets caught early.

Route C — on-device export (fallback)

Because the app keeps the book locally, a one-off export of an agent's own data is a pragmatic backfill when AA onboarding for a given insurer is still pending. Useful for the first load; not a live sync on its own.

For most teams the answer is Route A as the backbone, with Route B grafted on for the servicing fields and Route C used only to seed the first import. We say which fields come from which source in the spec, so nothing is ambiguous once it ships.

What gets built and handed over

The headline deliverable is code that runs against your own infrastructure:

• Runnable client SDK in Python and Node.js — authenticate, pull the agent's policies, and page through changes, returning typed objects rather than raw payloads.
• A delta-sync worker that tracks each policy by next-due date and status, so a re-run picks up only what moved.
• Webhook / callback handlers for AA consent notifications, so a granted or revoked consent updates state without a manual poll.
• An automated test suite with recorded fixtures for the policy and due-date surfaces, so a field rename shows up as a failing assertion.
• Normalized data model — one policy record across AA and portal sources (schema below).
• Secondary, but included: an OpenAPI description of the endpoints we expose, a protocol & auth-flow report (the AA consent handshake and the portal token chain), interface documentation, and a short data-retention note tied to the DPDP / IRDAI position.

What the client code looks like

Illustrative Python against the agent's book — field names are confirmed during the build, not assumed here.

# Authorized pull of an LIC agent's book (Perfect Agent Plus surfaces).
from openfin_lic import AgentBook, ConsentArtefact, ConsentExpired

book = AgentBook(
    agent_code = AGENT_CODE,
    consent    = ConsentArtefact.from_aa(handle),   # Account Aggregator consent handle
)

def changed_policies(since):
    try:
        for p in book.policies(updated_since=since):   # cursor on status + next_due
            yield {
                "policy_no":    p.policy_no,
                "plan_code":    p.plan_code,
                "life_assured": p.life_assured,
                "status":       p.status,        # in_force | lapsed | surrendered | revival_due
                "next_due":     p.next_due,      # date the premium-due intimation targets
                "mode":         p.mode,          # monthly | quarterly | half_yearly | yearly
            }
    except ConsentExpired:
        book.refresh_consent()                   # re-acquire before the next cursor run

# Club standing is derived, never a single stored flag:
fy = book.club_standing(fy="2025-26")
#   -> net_lives, first_commission, renewal_commission, lapse_ratio

One normalized record

Both routes land in the same shape, so downstream code never has to know which source a field came from.

{
  "policy_no":    "string",
  "plan_code":    "string",
  "life_assured": "string",
  "status":       "in_force | lapsed | surrendered | matured | revival_due",
  "next_due":     "YYYY-MM-DD",
  "mode":         "monthly | quarterly | half_yearly | yearly",
  "sum_assured":  0,
  "source":       "aa | portal",
  "agent_code":   "string"
}

Consent and the DPDP position

The Account Aggregator framework is governed jointly by RBI, SEBI, IRDAI and PFRDA, and nothing moves on it without the individual's consent, per Sahamati. IRDAI's part is to regulate the insurers that join as information providers and users; Sahamati notes its FIP/FIU counts under IRDAI grew through 2023 as more insurers came on, so coverage for a given life insurer is worth checking per project.

On the privacy side, India's Digital Personal Data Protection Act, 2023 applies. Legal analysis of the Act in insurance treats agents who set their own processing purposes as Data Fiduciaries; consent has to be free, specific, informed, unambiguous and withdrawable, and only the data a stated purpose needs may be collected. There is a real tension we design around: the Act's erasure right runs up against IRDAI rules that require certain policy and claim records to be retained. We build consent capture, consent records, logging and data minimization in from the start, with an NDA where the engagement needs one.

Build notes specific to this app

Three things about Perfect Agent Plus shape how we put the integration together.

• Local-first storage. The app saves the book onto the device for offline use. We ingest from the authorized data layer rather than a phone cache, and reconcile the on-device records against the AA / portal source so a re-pull never drops a policy the agent keyed while offline.
• Club standing is computed, not stored. An agent's tier comes from rolling figures — net lives, first and renewal commission, lapse ratio across three financial years — the way LIC's published club rules define them. We compute it the same way, so the standing we surface matches the official Branch / Divisional / Zonal Manager's and Chairman's Club tiers rather than a guess. (One source notes Chairman's Club requires 130 net lives a year for three years.)
• Due-date timing. LIC issues premium notices about a month before the due month, per its policy-status page. We set the sync window so a due intimation reaches your system ahead of that, not after the agent has already chased the client.

Screens from the listing

Store screenshots, for orientation on the surfaces above. Tap to enlarge.

Apps in the same corner of the market

Other tools an LIC or general-insurance agent might run alongside or instead of Perfect Agent Plus. Listed for ecosystem context — a unified integration usually has to read more than one.

• LIC Agent App (official) — agents' diary, policy alerts, renewals, and customer search by policy number, name, sum assured or plan code.
• LIC Agent Diary & CDR — client details and policy reminders, searchable by name.
• LIC Agent Diary — lightweight client list with reminder messaging.
• Smart Agent — multi-line agent app covering customers, policy types and premium tracking.
• Insurance Agent (com.dkgohil.insuranceagent) — client and policy manager with premium-due reminders.
• Policy Tracker & Reminder — premium-due tracking with WhatsApp, SMS and email reminders.
• InsureBook — policy management plus CRM for agents, brokers and policyholders.
• NFC LIC — policy lookup keyed on the LIC policy number.

Questions an integrator usually asks

Once we have pulled the initial book, how do you keep premium-due dates current?

We run a delta sync keyed on each policy's next due date and status. LIC issues its notices roughly a month before the due month, so we set the refresh window to land ahead of that and pull only the policies whose status or schedule changed since the last cursor, rather than re-reading the whole book each time.

Can policy status — loan, surrender, revival — come through the Account Aggregator route, or only the bare policy record?

The Life Insurance FI type on the Account Aggregator network carries the structured policy record and schedule. Richer servicing states such as loan, surrender value and revival eligibility are read through authorized interface integration against the agent's own portal session, then merged into one normalized record. We map which field comes from which source during the build.

The app uses an accessibility permission to auto-send messages. Does your integration depend on that?

No. The accessibility permission is how Perfect Agent Plus drives its own auto-messaging on the device; it is not our data path. We integrate at the data layer — the consented Account Aggregator feed and the authorized portal interface — so the records we deliver do not rely on screen automation.

Under the DPDP Act, who is the data fiduciary when we ingest an agent's client list?

An LIC agent who decides how client data is processed is generally a Data Fiduciary under the DPDP Act, 2023. We build the ingestion around free, specific, informed and withdrawable consent and collect only the fields the stated purpose needs, while accounting for the IRDAI record-retention rules that constrain outright erasure.

How this was put together

Checked in May 2026 against the app's store and product pages, the Account Aggregator FI-type catalogue and ReBIT's specification site, and published legal analysis of the DPDP Act in insurance. App metrics such as download count, rating and version are reported by third-party listings and treated here as approximate, not asserted. Primary sources opened:

• Sahamati — FI types available on the AA network (Life Insurance, live)
• ReBIT — Account Aggregator API specifications
• King Stubb & Kasiva — DPDP Act 2023 in the insurance sector
• Perfect Agent Plus — Google Play listing

Engineering notes compiled by OpenFinance Lab, checked 31 May 2026.

Source delivery starts at $300: we hand over the runnable client, the sync worker, tests and docs, and you pay once the build is in your hands and working. Or skip the code entirely and call our hosted endpoints, paying per call with nothing up front. Either way the cycle is one to two weeks, and access — consent artefacts, a sandbox or a consenting agent account — is arranged with you as part of the project. Tell us the app and what you want out of its data and we will scope it: Start a Perfect Agent Plus integration