Policy Register, FUP, and club-status data from Perfect Agent Plus

The data Perfect Agent Plus carries is an LIC agent's working file — Policy Register, FUP updates, premium-due lists, lapsed and SB-due reports, plan presentations, and the club-membership counter the agent watches every quarter. Per the developer site at perfectsoft.org.in the app is one of several "Perfect" products from Perfect Solutions (PS Soft) aimed at Life Insurance Corporation of India agents and Development Officers. The job we get hired for: move that working file off the device and into an agency CRM or a back-office database, with the agent's consent and a paper trail.

The bottom line. There is no banking rail here. Perfect Agent Plus is the agent's local ledger of their own LIC book; the data origin sits with the agent (their LIC portal account and their typing) and the holder is the device. So the integration we recommend rides the consenting agent — their authorization, their phone, their LIC portal login — and we map whichever of the app's own backup, share, or sync paths actually carry the rows.

What lives behind each screen

Pulled from the Play Store listing, the Indus Appstore page for the same package, and the feature list on perfectsoft.org.in, the practical data surfaces look like this:

Getting at it

Authorized interface integration on the agent's device

This is the spine. Working on a sandbox phone with a consenting LIC agent signed in, we instrument the running app — outbound traffic to any vendor backup endpoint, the on-device SQLite store, the share-intent payloads (CSV / PDF), the accessibility hook that drives the SMS sender. From that trace we describe each real surface as a named endpoint we can hit from the integration code. The build is bounded by the agent's account; the integration only ever sees rows that agent owns.

Agent-consented credential sync to the LIC agent portal

Several of the rows in Perfect Agent Plus are restatements of what the LIC agent portal shows the agent. Where a CRM needs canonical numbers (in-force list, lapse list, due statements as the insurer sees them) we set up a parallel pull straight from the agent's LIC portal session with their explicit consent. We rotate, scope, and log the credential the same way; the portal's own challenges (OTP, captcha) stay visible to the agent.

Native export from the app

Perfect Agent Plus offers Save Presentation in PDF and SMS/Share options, per the developer feature list. Where the volume is small or the agent prefers the lightest footprint, the integration is a parser around those exports — a watcher that picks up the file the agent shares, normalizes it, and posts it to the CRM. Fewer moving parts, narrower coverage.

Picked as the spine for most builds: route one, with route two layered in when the CRM needs the insurer-side view too. Route three is a clean fallback for one-agent micro-engagements.

An endpoint sketch from a real surface

Illustrative — exact field names are confirmed during instrumentation on the consenting agent's device. A typical "policies due in the next 30 days" pull from the mapped layer looks like:

GET /api/v1/agents/{agent_id}/policies/due?window=30d
Authorization: Bearer <agent-scoped token, rotated>
X-Consent-Id: <DPDP consent reference, JWT>

200 OK
{
  "agent_id": "ABCDE-1234",
  "as_of": "2026-05-20",
  "window_days": 30,
  "policies": [
    {
      "policy_no": "123456789",
      "life_assured": "REDACTED_AT_SOURCE",
      "plan_code": "914",
      "mode": "QLY",
      "sum_assured": 500000,
      "premium": 6342,
      "fup": "2026-06-12",
      "lapsed_after": "2026-12-12",
      "club_contribution": { "net_lives": 1, "premium_to_club": 6342 }
    }
  ]
}

What lands in your repo

For an engagement this size the studio hands over:

• An OpenAPI 3.1 spec covering the mapped surfaces — policies, FUP, dues, lapsed, SB-due, maturity-due, club-status counter, plus the share / export watcher if route three is in scope.
• Runnable source in Python (httpx + Pydantic) and a Node.js (TypeScript) variant for the same endpoints. Auth helper, token rotation, retry-with-jitter, and a consent-id header on every call.
• A protocol & auth-flow note describing how the LIC portal session is acquired, how the on-device SQLite is read on the analysis device, and which fields are normalized into the canonical schema.
• A normalized JSON schema for the agency book — one policy row, one due row, one club-status row — that drops into Salesforce, Zoho, or a custom Indian agency CRM through webhook or pull.
• Pytest and Vitest suites: contract tests against the mapped surfaces, replay tests against captured fixtures, plus a small chaos pack that mimics the LIC portal's OTP step.
• An interface document for your team — the screen-by-screen map, the field-by-field map, and the consent / retention notes per row.

Quirks we account for during the build

A few things specific to this app shape how the engineering runs. We handle them; they are not asks on you.

The Android Accessibility hook is a sender, not a source. The Play Store note that accessibility permission is needed "for sending automatically messages" describes a control surface — that hook drives the device's SMS app, it is not a data store. The integration code does not lean on it. If outbound SMS is part of the integrated stack we replace it with a TRAI DLT-registered gateway on the server side, which is the right place for that traffic anyway under the Indian SMS rules.

The LIC club thresholds change every cycle. Per the LIAFI club-rules compendium, club tiers (Branch Manager, Divisional Manager, Zonal Manager, Chairman, Galaxy, Corporate) attach to net-lives and net-premium counts that the central office revises. We codify the current cycle's thresholds as data, not constants, so the dashboard does not drift when LIC publishes the next compendium.

The portal layer changes more often than the app layer. The agent's LIC portal HTML, the OTP flow, and the report layouts get reworked from time to time. We build the route-two pull with a thin scraper layer behind a stable internal interface, and ship a re-validation harness that flags structural drift before a sync run fails in the field.

One agent's data must not bleed into another's. Two agents who use the same CRM tenant still have legally separate books. We carry the agent identity through every call, key the storage by agent, and write the data-minimization rule (life-assured names redacted to the CRM unless the agent and policyholder consent for marketing) into the schema itself rather than the README.

DPDP, IRDAI, and the agent's consent

India brought the Digital Personal Data Protection Act 2023 into force and the IRDAI Information & Cyber Security Guidelines 2023 sit alongside it; PwC India's writeup on the insurance-sector impact lays out how insurance agents are treated as data fiduciaries in the value chain rather than mere passers-through. For a Perfect Agent Plus integration that means the lawful basis we build on is the agent's authorization (their book, their device, their portal account) plus the agent's documented consent on behalf of their policyholders for the specific processing — sync to the CRM, retention window, withdrawal path. Consent records are kept with the data, not in a separate spreadsheet, and the same consent reference travels on every API call. Mondaq's coverage of the DPDP Rules in the insurance sector flags the heavy obligations around data-principal rights — access, erasure, grievance — and the engagement scopes a small handler service that fields those requests against the synced rows from day one. IRDAI's task force on DPDP impact is still working through sectoral specifics, so the integration's compliance log is built to take additional fields without a rewrite.

Worked scenarios

Three shapes the engagement usually takes, drawn from real conversations:

• Agency back-office migration. A senior agent with around 1,800 policies on Perfect Agent Plus moves to a new agency-CRM. The integration is one-shot: instrument the app, pull the Policy Register, FUP, and due lists, normalize, and load. Route three (share-watcher) is used to catch the long tail of PDF plan presentations.
• Development Officer roll-up. A DO who supervises 20 agents wants a live roll-up of the team's book — total in-force, total lapsed, total club contribution by agent. Route one runs per agent (each consents on their own device); the DO sees the aggregate, not row-level life-assured data.
• SMS-out replacement. An agency wants to drop the Accessibility-driven SMS path and route all renewal reminders through a DLT-registered gateway. The integration ports the Combo Greetings templates and the due-trigger logic, leaves the rest of Perfect Agent Plus alone.

Inside the app

Screens referenced above. Click to enlarge.

What I checked

For this brief the integration desk read the Play Store listing for the package, the Perfect Solutions developer site for the broader feature list (which covers products beyond just this app), the LIAFI compendium for the current club-rules thresholds, and PwC India's analysis of the DPDP Act's bite on the insurance value chain. Sources opened:

• Perfect Agent Plus on Google Play
• Perfect Solutions — LIC / insurance / post-office agent software
• LIAFI — LIC Club Membership rules (Elite club PDF)
• PwC India — DPDP Act implications for the insurance sector

Mapped by the OpenBanking Studio integration desk, May 2026.

Adjacent apps in the same data layer

Other apps a LIC agent or DO is likely already touching. Listed neutrally — the same integration patterns apply when an agency runs more than one of them.

• LIC Agent App — the official LIC app for agents, with agent diary, appointments, alerts, booked-business and renewals data direct from the insurer.
• Bimamitra (com.spysoft.bima) — all-in-one agent app with plan combinations, policy status, and loan-management views, sourced from agent input plus portal lookups.
• PolicyApps — software for LIC agents and Development Officers, offline policy tracking with filter and sort, similar Policy Register-style table as the primary surface.
• LIC Stickynote Agent App — client-policy tracker with Google account backup; useful when the integration needs to onboard agents who store off-app.
• Perfect Policy (ABC Developers, perfectpolicy.org) — adjacent LIC policy tracker, similar data domains to Perfect Agent Plus.
• LIC Ananda — LIC's onboarding and proposal app; useful upstream of the Policy Register once a sale closes.
• LIC Customer App — policyholder-side companion; relevant when the agency CRM also serves the policyholder view.
• LIC Perfect Agent Manager (perfect.agentmanager) — a sister product from Perfect Solutions, overlapping with this app on policy and due data.

Questions a LIC-agency integrator asks

Does the app keep its policy ledger locally, or does it sync to a Perfect Solutions server?

From what the Play Store listing and the developer site describe, Perfect Agent Plus reads as a device-side data manager — Policy Register rows, FUP updates, and due lists sit in a local store on the agent's phone, populated by the agent. There may also be a backup or sync path through the vendor; during the build we trace the app's outbound traffic on the consenting agent's device and map whichever it actually uses.

Can the FUP and premium-due data feed straight into an existing agency CRM?

Yes. Once the surfaces are mapped we hand over normalized JSON for policies, FUP entries, premium-due rows, lapsed and SB-due lists, and the club-status counter, in a shape an agency CRM such as Salesforce, Zoho, or one of the Indian agency-CRM stacks can ingest by webhook or pull endpoint.

How does the accessibility-permission SMS hook affect what we can integrate?

The auto-message feature uses Android Accessibility services to dispatch SMS through the device — it is a sender, not a data store, so the integration centres on the policy and agency-data layer, not the messaging path. If you also want outbound SMS on the integrated stack we wire that separately through a licensed Indian SMS gateway under your TRAI DLT registration.

If a LIC agent's portal login changes, how does the sync handle that?

The credential layer is built with rotation in mind: encrypted at rest, scoped to the one agent who consented, and re-validated on each pull. When the LIC portal throws OTP or a fresh captcha the sync surfaces the prompt to the agent rather than failing silently — the agent stays in the loop.

Source for the mapped endpoints, the test pack, the OpenAPI doc, and the interface notes is handed over for $300 once you have it running and are satisfied — payment after delivery, not before. If you would rather call our hosted endpoint and settle per call, that is the second model and there is no upfront fee. A working build lands in one to two weeks. Reach the integration desk with the app name and your target CRM; access, the sandbox agent device, and the DPDP paperwork are arranged with you during onboarding.

App profile