Bimafy keeps every policy, quote and claim server-side — the authorized way in

What a Bimafy account actually stores

A Bimafy account ties one Bangladeshi user to the quotes they pulled across insurers, the policies they bought, and every claim they filed through the in-app portal. That is the value for an integrator: it is not one carrier's book, it is a single account spanning several. Bimafy's own site is explicit that it is a platform to avail insurance products and services digitally, not an insurance company — so the data behind the login is the account holder's, aggregated by Bimafy from the carriers that underwrote each policy.

The bottom line first. A consumer-facing aggregator with a real claim portal carries structured, per-user records worth syncing, and the authorized way to reach them is to analyse the app's own traffic under the account owner's consent or your written authorization. We would treat the protocol route as the spine and keep the policy-document download as a fallback for the fields it carries.

Routes into the policy and claims data

Three routes genuinely apply here. They are not equal, and we would not pretend otherwise.

Protocol analysis of the app's traffic, under authorization

The app authenticates a session and then calls Bimafy's own backend for the policy list, a policy's detail, and a claim's state. We observe that exchange on a consenting account, document the auth handshake and the request and response shapes, and rebuild the calls as a clean client. Reach is the widest of the three — anything the app itself shows a logged-in user. Effort is moderate; durability is good because the shapes change slowly and any change is caught by tests. Access is set up with you during onboarding against a consenting account or a test login you provide; we handle that, it is not a hurdle you clear before we begin.

User-consented credential access

Where a person wants their own Bimafy data moved, the same calls run under their explicit, revocable consent rather than a controller's authorization. Identical reach, different legal basis — useful for a one-person migration or a consented sync, and we record the consent the same way we would a controller mandate.

Native document export

Bimafy issues a digital policy copy by email and lets the holder download it from the Profile > Policies area. That is a narrow but reliable fallback: it carries the policy terms cleanly but not live claim state or quote history. We use it to corroborate parsed fields, not as the primary feed.

Recommended: the protocol route as the working spine, the document export folded in to validate policy fields, and consented access offered where the request is one user moving their own records. We say which on a call once we see what you need out of the account.

A worked call: sign in, list policies, read a claim

Illustrative only — field names and the token shape are reconstructed during the build against a consenting account, not published constants:

# 1. Authenticate (mobile + OTP path observed in the app)
POST /api/v1/auth/otp/verify
  { "phone": "+8801XXXXXXXXX", "otp": "######" }
-> 200 { "access_token": "ey…", "refresh_token": "…", "user_id": "u_…" }

# 2. List the account's policies
GET /api/v1/policies            Authorization: Bearer ey…
-> 200 [
     { "policy_id": "p_8842", "line": "health",
       "insurer": "",
       "sum_insured": 500000, "currency": "BDT",
       "status": "active", "ends_on": "2026-11-30",
       "doc_url": "/policies/p_8842/document" } ]

# 3. Read one claim's state
GET /api/v1/claims/c_2207       Authorization: Bearer ey…
-> 200 {
     "claim_id": "c_2207", "policy_id": "p_8842",
     "state": "under_review",          # submitted|under_review|approved|settled|rejected
     "documents": ["prescription","hospital_bill","discharge"],
     "payout_channel": "mfs",          # mfs|bank
     "assist_notes": "Bimafy following up with insurer" }

# Error handling we wire in:
#  401 -> refresh once with refresh_token, then re-auth
#  429 -> respect Retry-After; the claim portal is rate-sensitive
#  claim 'state' is mapped to an enum so a new label fails a test, not the sync
      

What ships to your team

Concrete artefacts, each tied to a Bimafy surface above:

• An OpenAPI 3 description covering the auth exchange, the policy list and detail, and the claim read — with the insurer kept as a field so multi-carrier accounts stay coherent.
• A protocol and auth-flow report: the OTP / token path, refresh behaviour, and how the claim portal differs from the policy endpoints under load.
• Runnable source for the key calls in Python and Node.js — sign-in, policy enumeration, single-policy detail, claim status, document fetch — with the retry and enum-mapping logic shown above.
• An automated test suite that pins the observed request and response shapes, so a renamed field or a new claim state fails loudly.
• A normalised schema that flattens the per-line differences (health vs motor vs travel) into one policy and one claim model.
• Interface documentation plus data-retention and consent-record guidance written for an IDRA-regulated, Bangladesh-resident dataset.

IDRA, a data law still in draft, and how we keep this clean

Insurance in Bangladesh is overseen by the Insurance Development and Regulatory Authority, the sole statutory body for the sector since the IDRA Act and Insurance Act of 2010 (IDRA constituted in 2011, per its public record). IDRA also runs its own policyholder-facing digital work — a unified messaging platform and e-policy repository — which is context, not our data source: our subject is the Bimafy account holder's records.

On personal-data law the honest position is that Bangladesh has no comprehensive data-protection statute in force; the bill has gone through repeated draft revisions and is not settled, so this brief does not state its thresholds or retention periods as if they were live obligations. A national open-banking framework has only been reported as planned by Bangladesh Bank, not enacted, so we do not route this work through an open-banking scheme that does not yet exist. What we operate to instead is concrete: access only under the account owner's consent or your written authorization as the commissioning controller; a consent record and an access log kept for every run; data minimised to the policy and claim fields you actually need; and an NDA where the engagement calls for one. That posture is how the studio works, not a gate you pass before we start.

What a Bimafy build has to plan around

Two things shape a Bimafy integration specifically, and we account for both:

• One account, several underwriters. Because Bimafy aggregates carriers, two policies on the same login can come from different insurers with different field sets. We carry the underwriting company as a first-class field and branch parsing per line of business, so a health policy and a motor policy in one account both normalise correctly rather than the second one breaking the first.
• The claim portal is a state machine, not a snapshot. A claim moves through submission, the Bimafy-assisted follow-up, insurer review, approval and settlement, with documents attached along the way. We model those transitions explicitly and design the sync around them, so an approval or a payout is reflected instead of the record freezing at "submitted".
• Identity is multi-path. Sign-in can be mobile-OTP, email, Google or Apple; we make the client tolerant of the path the account actually uses and centralise refresh so a long sync does not silently drop its session.

Keeping the feed accurate as Bimafy reships

Bimafy ships one backend to both Android and iOS, which helps: a contract reconstructed from one client generally holds for the other, and most app updates touch presentation, not the auth flow. Two failure modes still matter — a new claim-state label, and a field rename on the policy object. Both are pinned in the test suite as fixtures, so they surface as a failing test rather than a quietly wrong sync. If you take the maintenance option, a re-validation pass runs against a consenting account after notable app releases.

Screens we walked through

Store screenshots used while mapping the policy list, the claim flow and the comparison journey. Select to enlarge.

Where Bimafy sits among Bangladesh insurance apps

Bimafy is the aggregator; most peers are single-carrier or regulator apps, which is exactly why a normalised model across them has value. Neutral notes, no ranking:

• One by MetLife Bangladesh (formerly 360Health) — a single insurer's app: premium payment, policy certificates and transaction history for MetLife customers.
• MyGuardian / Guardian Life — Guardian Life's app, including EasyLife online term life; policy management and claims for one carrier.
• Bima Tathya — IDRA's policyholder app over its unified platform; policy verification and an information channel rather than a marketplace.
• InsuMama — Green Delta Insurance's AI-assisted app for that insurer's products.
• Pragati Life Insurance — a life insurer's own digital servicing for its policyholders.
• Sonali Life Insurance — another single-carrier life insurer presence with policy servicing.
• Labaid InsureTech — a multi-line digital insurance platform launched in the same aggregator space.
• Instasure — an insurtech building products with carriers such as Pragati Life; a backend-integration counterpart rather than a consumer marketplace.

An integrator dealing with several of these wants one policy and one claim model regardless of which app the record came from — which is the schema we deliver.

Questions integrators actually ask about Bimafy

Bimafy aggregates many insurers — does that change how the policy data comes back?

It does, and we design for it. A Bimafy policy record carries the issuing insurer alongside the coverage, sum insured and remaining duration, so the same account can hold a health policy from one carrier and a motor policy from another. We normalise to one schema with the underwriting company kept as a field, so a downstream system can group by user or split by insurer without re-parsing each policy type.

Can claim status and the documents attached to a claim be pulled, or just the policy header?

The in-app claim portal exposes more than the header. A claim filed through Claim Now carries its state, the assisted-journey notes Bimafy adds while the insurer processes it, the document set the user uploaded (prescriptions, hospital bills, discharge and diagnostic reports) and the chosen payout channel. We map claim state transitions explicitly so a sync reflects approvals and settlement rather than only the initial submission.

Bimafy is not the insurer — whose authorization actually covers this work?

Bimafy describes itself as a platform to avail insurance products, not an insurance company, so the data we reach is the Bimafy account holder's own quotes, policies and claims. Work runs under the account owner's consent or your written authorization as the data controller commissioning it, recorded before the build. Insurer-side records held by the underwriting company are out of that consent and we do not represent otherwise.

What happens to the integration when Bimafy reships the app?

Bimafy ships the same backend to Android and iOS, so a contract built from one client usually holds across both, and small payload changes rarely move the auth flow. We pin the observed request and response shapes in the test suite, so a field rename or an added claim state fails a test instead of corrupting a sync, and a re-validation pass is part of the maintenance option if you take it.

What was checked, and when

Reviewed on 2026-05-17. The mapping draws on Bimafy's own FAQ and product pages for the claim flow, login methods, lines of business and the platform-not-insurer statement; on IDRA's public record for the regulator and the 2010 statutes; on a DLA Piper country guide for the unsettled state of Bangladesh data-protection law; and on press reporting of Bangladesh Bank's planned open-banking work for regulatory direction. Primary sources, opened directly:

• Bimafy FAQ — claims, login, policy delivery
• IDRA — mandate and the 2010 statutes
• DLA Piper — data protection status, Bangladesh
• Bimafy on Google Play (com.bimafy)

Bimafy interface notes by the OpenBanking Studio integration desk — reviewed 17 May 2026.

Source built against Bimafy's own sign-in, policy and claim calls lands in your repository for $300, invoiced only after delivery once it works for you. Prefer not to run anything yourself? The same endpoints are available as a metered hosted API with nothing paid upfront — you pay per call. A build runs one to two weeks. Tell us the app and what you need out of the account at /contact.html; access, the consenting account or test login, and any NDA are arranged with you from there — that part is our job, not a checklist you complete first.

Mapping updated 2026-05-17.