Bridge Cure:
every financed health claim carries its own evidence.
One document that explains what the platform is, who uses it, how money and medical records move across it, and why this is the moment to build it. Written for founders, new team members, lenders, hospital owners and anyone who needs to understand BC without reading the full BRD and SDD.
What problem is Bridge Cure solving?
In one sentence: a hospital delivers care today but is paid by the insurer 30 to 90 days later — and sometimes only part of it — because the insurer cannot easily trust the paperwork; banks will not lend against that unpaid money because they cannot see proof; and the patient, who owns the underlying data, is in the dark. BC fixes the missing ingredient: trusted, consented, signed evidence.
The money exists. It is stuck between a promise and a bank account.
When an insured patient is treated cashlessly, the hospital does not get paid at the bedside. The insurer or its third-party administrator (TPA) first approves the treatment (pre-authorisation), then, after discharge, reviews the bill and the clinical documents, and only then pays — often with deductions. During that gap the hospital has already paid for doctors, nurses, drugs and electricity.
Four people feel the pain, differently
Cash trapped in receivables
A 40-bed hospital might have ₹40 lakh+ of approved claims outstanding at any time. Salaries, oxygen suppliers and pharmacy vendors do not wait 60 days. A single "rejected — documentation" mark can erase a month's margin on that patient.
Cannot underwrite what it cannot see
A receivable from a large insurer is attractive in theory. In practice a lender cannot tell whether the bill matches the treatment, whether the same claim was already pledged elsewhere, or how often this insurer short-pays this procedure. So most banks do not lend here at all.
Drowning in scanned bundles
Every claim arrives as PDFs and photographs. Staff must check authenticity by eye, chase missing documents and guard against fraud — while a regulator now expects cashless decisions in hours and settlement within days.
No ownership, no explanation
The patient's discharge summary sits in a hospital cabinet. When a claim is cut, they rarely know why. When they change hospitals, they carry a bag of photocopies — and the new doctor repeats tests.
Scene (fictional, from the BC requirements): Sunrise Hospital, a 40-bed hospital in Nashik, has ₹41 lakh of approved cashless claims sitting unpaid on its billing desk. One has been waiting 61 days. Four are marked "rejected — documentation". Owner Dr Joshi has to tear up the salary cheque and write a smaller one. Nothing was wrong with the care. The problem is that the insurer's reviewer cannot quickly verify the paperwork, so the safe move is to delay or deduct.
Real-world anchor: India's regulator IRDAI reports that in FY25 insurers settled about 87% of registered health claims, repudiated about 8% and left about 5% pending — on 3.26 crore claims worth ₹94,248 crore. The "8% repudiated" sounds small until you see it is roughly 26 lakh claims in a single year.
Why this is an evidence problem, not a money problem
India already has lenders, insurers and good hospitals. What is missing is a shared, tamper-evident record of what happened to the patient that all three parties will accept. When an insurer cannot verify, it delays or denies. When a lender cannot verify, it declines. When a hospital cannot prove, it loses appeals. Bridge Cure sells the missing proof — and then uses that proof to unlock cash.
Think of what UPI did for payments: it did not create money, it created a rail where any bank could trust any other bank's instruction instantly. BC aims to be that kind of rail for the question "did this treatment happen, was it consented to, and is this claim safe to pay or lend against?"
How is Bridge Cure solving it?
BC is one platform with two inseparable capabilities: a Verified Health Record (a hospital-signed, patient-held, consent-gated record that travels with the claim) and a Claims Liquidity Exchange (a regulated lender advances 80–88% of an approved claim within days, repaid automatically from the insurer's payment). The record makes the claim safe to finance; the financing makes the record worth issuing. BC itself is a technology rail, not a lender, insurer or consent manager.
Verified Health Record (VHR)
At discharge, the hospital issues a clinical record (a FHIR bundle) and digitally signs it. The patient receives it encrypted on their own phone and consents to who may read it. A fingerprint (hash) of the record is anchored in a public, append-only transparency log, so nobody — including BC — can quietly change it later. An insurer later verifies a signature and an anchor instead of squinting at a scan.
Claims Liquidity Exchange (CLX)
A bank or NBFC pre-sanctions a credit limit for the hospital. Each claim that is certified (treatment, bill and authorisation all agree) can be drawn against — typically 80–88% — and the money moves bank to bank. When the insurer pays, a standing instruction on the escrow account repays the advance automatically. Shortfalls are netted gently, never clawed back at once.
The six-link chain of evidence
Every step leaves an artefact that the next step relies on, linked by identifiers and hashes rather than trust. An auditor can walk from a rupee in escrow back to the signature on the discharge summary.
Hospital signs
The discharge record is signed with the facility's registered key (tied to its ABDM facility ID).
Patient consents
Purpose, scope and expiry are chosen by the patient and signed on their phone. Silence is not consent.
Three-way match
BC checks the treatment record, the bill and the insurer's authorisation agree on dates, facility, amount and patient reference.
Lender advances
One advance per claim, enforced by a database key. Money goes from the lender's bank to the hospital's bank.
Insurer verifies
Under a time-boxed consent, the insurer's reviewer checks signature and anchor; the patient sees the view in their access log.
Sweep and ledger
The insurer pays a collection account; the advance is repaid; any variance is written to an append-only ledger.
What BC deliberately does not do
- It does not lend. Regulated lenders do, from their own balance sheets (BC is a "lending service provider" under RBI's Digital Lending Directions).
- It does not hold money. No BC-controlled account is in any money path.
- It cannot read patient records. BC stores ciphertext and hashes. The key is generated on the patient's phone.
- It does not use a blockchain or tokens. Anchoring is a witness-co-signed transparency log with licensed timestamps (the same idea as Certificate Transparency on the web).
- It does not let machines decide. OCR output, denial warnings and appeal drafts are advisory; named humans confirm, release stops and submit appeals.
Analogy: a courier company vs a postal rail. A lender that finances hospital bills is like a courier — it competes on price of capital, which a startup cannot win. BC is more like the postal system's tracking-and-sealing layer: sealed envelope (signed record), signature on delivery (verification event), and tracking number (hash-chained ledgers). Couriers — the lenders — are customers of the layer, not rivals to it.
How does it work between hospitals, banks and insurance companies?
Three organisations, one claim, five flows. The hospital creates the evidence, the insurer is the eventual payer, and the bank bridges the time gap in between. BC sits in the middle as a neutral rail: each party sees only what it is entitled to see, and every handoff is a signed, logged event.
Walk one claim end to end — click through
Fictional cast, illustrative dates: Sunrise Hospital (40 beds, Nashik) · patient Ramesh · MedAssist TPA acting for Bharat Suraksha insurance · Deccan Finance (NBFC lender).
Who does what — the three-party view
| Moment | Hospital | Bank / NBFC (lender) | Insurer / TPA (payer) | BC platform |
|---|---|---|---|---|
| Onboarding | Applies with PAN, GSTIN, clinical-establishment registration, bank account and a named signatory | Recorded with its RBI registration; its staff are created under four-eyes approval | Onboarded as a PAYER tenant with its IRDAI registration | Maker prepares, a different checker approves; tenant and first admin are created in one transaction |
| Credit line | Digitally signs the facility terms | Sets limit, rate in basis points, fee, tenor; countersigns | — | Stores the one terms digest both sides signed; a signature over different terms cannot be stored |
| Discharge | Files the claim, issues and signs the record | — | Pre-authorised the amount earlier | Patient consents; hash anchored; claim certified by three-way match |
| Funding | Draws an advance against the certified claim | Disburses bank to bank | — | Checks headroom, facility signed, no hard stop, one advance per claim |
| Verification | Responds to queries | Sees the verification event bound to the claim | Verifies signature and anchor under a time-boxed consent | Logs every view to the patient within seconds |
| Settlement | Receives any surplus after repayment | Gets principal and discount back through the sweep | Pays into a collection (escrow) account | Reconciles the bank feed; writes variance to the ledger |
| TOTAL money held by BC at any point: ₹0 — every rupee moves between the parties' own bank accounts. | ||||
What each party can and cannot see
| Information | Hospital | Lender | Insurer / TPA | Patient |
|---|---|---|---|---|
| Clinical record | Own patients | Never | Only during consent window, in scope | Always (own) |
| Claim financials | Own claims | Claims it funds | Claims it is party to | Summary view |
| Another lender's book | No | No (row-level security) | No | No |
| Lender pricing | Own facility | Own | Never | No |
| Insurer's own variance profile | Own deductions only | As an underwriting input | Its own, never another payer's | No |
| The measured party (insurer) may see its own measurement and nothing derived from it for others. | ||||
Why the insurer cooperates: IRDAI's master circular expects insurers to answer cashless pre-authorisation within one hour and give final discharge approval within three hours, and to bear the extra cost of delay from shareholders' funds. A reviewer who can verify a signature in seconds, instead of reading a scanned bundle, can meet that clock. And the insurer's own appeals desk sees fewer disputes because the record is signed.
What are the external interfaces?
BC plugs into thirteen kinds of outside system: the national health stack (ABDM: ABHA, registries, consent manager, locker roles, Fidelius/FHIR), the national claims exchange (NHCX), banks, hospital software, messaging, key management, a transparency log with independent witnesses, passkeys, and regulatory adapters. It also exposes its own API and four user-facing surfaces. Everything outside BC's boundary is reached through one gateway with mutual TLS, scoped tokens and rate limits.
| Interface | What it is | What BC uses it for | Status |
|---|---|---|---|
| ABHA Ayushman Bharat Health Account | National health ID; 93.95 crore created as of 10 Jul 2026 | Patient sign-in. BC issues no patient password or credential; it holds only the ABHA address and linked references. | Gated · ABDM M1 |
| HFR / HPR Facility & professional registries | 5.33 lakh facilities and 9.85 lakh professionals registered (Jul 2026) | A hospital's signing key is bound to its HFR ID so an insurer can tell who issued a record. | Planned |
| ABDM consent manager | The official service that carries a consent request from a data user to the patient and back | BC verifies and enforces consent artefacts; it never mints them. It is deliberately not itself the consent manager. | Gated · M2 |
| HIP / HIU / Health Locker | ABDM roles: information provider, information user, and a store that does both | BC occupies the "Health Locker" slot as a verified-only locker: it receives hospital-signed records and serves them to the next hospital or insurer under consent. | Gated · M1–M3 + CERT-In audit |
| Fidelius & FHIR R4 | ABDM's end-to-end encryption protocol and the clinical data standard | The envelope in which records travel; the format of the signed bundle. | FHIR library built Fidelius planned |
| NHCX National Health Claims Exchange | One FHIR "wire" for insurers, TPAs and hospitals. Not legally mandatory in 2026 but tied to government incentives (DHIS). | The structured claim envelope; BC attaches a record reference and consent ID to it. | Planned |
| Lender's nodal & escrow banks | The bank accounts through which money actually moves | Disbursement instructions (lender → hospital), a collection account for insurer payments, a standing instruction that sweeps repayment, and a bank-statement feed that BC reconciles. | Gated · lender agreement + escrow mandate |
| Hospital information systems (HIS) | The billing/EMR software hospitals already use | Partner SDK/API pushes claim fields; hospitals with no API photograph bills and a named BC operator confirms the OCR figures within a 4-hour SLA. | OCR + review desk built HIS SDK planned |
| SMS / email gateway | Message delivery | One-time codes for hospital and lender staff, expiring consent links for patients without ABHA. | Built (dev: logged) |
| KMS / HSM | Managed key custody | Platform signing keys and the audit of any escrowed patient key (opt-in only). | Planned |
| Transparency log, witnesses & licensed timestamp authority | An append-only public log (RFC 9162 design) co-signed by independent witnesses | Anchors record hashes, consent hashes and ledger heads so tampering is detectable by anyone. | Anchor service built Witnesses/TSA planned |
| WebAuthn passkeys | Phishing-resistant sign-in standard | Sign-in for BC's own operators. | Built |
| Regulatory & credit adapters | Trade-credit-insurance wrapper, cross-border SPV channel, receivables/credit-information reporting | Each is designed and built as a capability that is born OFF and can only switch ON against a maker-checker record citing counsel's written opinion. | Gated · counsel |
| TOTAL: 13 external interface families · 0 BC-controlled money accounts · 0 plaintext clinical records leaving the patient's device and hospital. | |||
BC's own surfaces (what people actually touch)
Bridge Cure app
Sign in with ABHA. Hold signed records encrypted on the phone. See every rupee approved, paid and deducted with the reason. Revoke access in one tap.
Bridge Cure Partner
Issue records at the bedside, sign facilities, draw advances; lender credit, operations and risk roles use the same app.
Bridge Cure Trust
Scoped, time-boxed verification of a signed record under consent — signature and anchor already checked for you.
Operator console
Human-in-the-loop document review with SLA timers, maker-checker approvals, and switches for regulated capabilities.
Behind these sit eleven services on one PostgreSQL cluster with row-level security, one message bus and one gateway. The contract is published as OpenAPI documents — 156 API operations in the 1 Oct 2026 snapshot.
A claim crosses five interfaces in 24 hours: Sunrise's billing executive files it in the Partner app (BC surface) → the hospital's key signs the record, bound to its HFR facility ID (ABDM) → Ramesh consents through the consent manager and his phone (ABDM + device) → the claim envelope reaches MedAssist on NHCX → Deccan Finance's nodal bank credits Sunrise's account (banking rail). Five outside systems, one chain of hashes.
How does BC make lending safe for banks?
By turning a promise into an underwritable asset. A lender on BC finances only claims that are certified against a hospital-signed record, can fund each claim only once, sees measured insurer behaviour rather than guesses, is repaid by an automatic sweep from escrow, and is protected by hard stops that a named human must release. Crucially, these are not policies — most are database constraints that code cannot bypass.
Ten controls, and what each one prevents
No evidence, no advance
An advance references a certified claim by foreign key. The three-way match (treatment · bill · authorisation) must agree on dates, facility, amount and patient reference. Prevents: lending against padded or mismatched bills.
Double-financing is a unique key
UNIQUE (claim_id) on the advance table. A hospital cannot pledge the same receivable to two lenders because the second draw is rejected by the database. Prevents: the classic invoice-discounting fraud.
Both sides sign the same digest
Limit, rate (in basis points), fee, tenor and expiry are hashed; the hospital and lender both sign that exact digest. A signature over different terms cannot be stored. Prevents: disputes about what was agreed.
Bank-to-bank, with a sweep
Insurer receipts land in a collection (escrow) account whose standing instruction repays open advances first. No BC account exists in any money path. Prevents: cash being diverted or commingled.
Measured, not assumed
Every settlement short-payment is written to an append-only, hash-chained ledger — no update or delete grant exists. Variance by payer and procedure class feeds the lender's pricing. Prevents: underwriting on hope.
Three tripwires halt new draws
Default thresholds: variance over the window above 12%; one payer above 40% of the outstanding; secondary loss reserve below its floor (default 1.5× trailing variance). Only the lender's credit officer can release a stop, and the release is ledgered with their name. Prevents: slow-motion portfolio deterioration.
Each lender sees only its own book
Row-level security keyed on the bound lender covers every financing table. Lender B's session reads zero rows of lender A's — proven per table in the build gate. Prevents: leakage of competitive pricing.
Regulated powers need two humans
Disbursement, escrow sweep, co-lending and credit enhancement are switches that start OFF and turn ON only against an AUTHORISED maker-checker record referencing a signed out-of-band document. Code alone cannot switch them on. Prevents: a bug or rogue engineer enabling money movement.
No floating point, ever
Amounts are stored as integer paise (strings in APIs); rates are basis points. A rounding drift of one paisa across millions of claims is structurally impossible. Prevents: reconciliation breaks.
Machines advise only
OCR figures are confirmed by a named operator; denial-prevention checks block nothing; appeals are submitted by a person; every adjudication is recorded. Prevents: an opaque model gating a loan.
Try it — the claim waterfall and the hard-stop dashboard
A. One claim: what happens when the insurer pays short?
Based on the BRD's worked example: certified ₹1,60,000 · advance at 80% · fee ₹500 · next remittance ₹3,40,000 netted at 20%.
B. Portfolio tripwires
Why the record moves the numbers (illustrative unit economics)
Per ₹100 crore a lender advances in a year, the founders' model assumes the signed record lowers short-payment variance from 8.0% to 5.0%, which lowers the reserve the lender must hold and lifts the advance rate it can safely offer:
| Per ₹100 cr advanced / yr | Without record | With record | Delta |
|---|---|---|---|
| Short-payment & repudiation variance | 8.0% (₹8.0 cr) | 5.0% (₹5.0 cr) | ₹3.0 cr less loss |
| Secondary loss reserve (1.5× variance) | ₹12.0 cr | ₹7.5 cr | ₹4.5 cr released |
| Advance rate offered | 80% | 88% | +8 pts of liquidity to hospitals |
| BC take rate borne by lender | 35 bps | 45 bps | +10 bps |
| Verification fees (₹75 × ~34,500 claims) | ₹0 | ₹0.26 cr | +₹0.26 cr |
| TOTAL attributable to the record ≈ ₹7.86 cr per ₹100 cr advanced — an assumption to be replaced with pilot data. | |||
Hard stop in action (BRD example, fictional): In February, Sunrise's variance with MedAssist over 45 days reaches 13.1% after a run of short-payments on cardiac claims. New draws stop automatically; Dr Joshi's screen says why in plain words; credit officer Suresh at Deccan Finance sees the same figure. After Sunrise's appeals succeed, Suresh releases the stop on 3 March with a note — a ledgered act with his name on it. Nothing releases automatically.
Real-world parallel: this is how trade-receivable platforms such as TReDS work for MSMEs — the lender funds only invoices that the buyer has acknowledged on a shared platform. BC extends the same "acknowledged, single-financed receivable" logic to hospital insurance claims.
How does BC make sure hospitals are happy with the service?
By paying them in days, deducting less, and never surprising them. A hospital draws cash against a certified claim typically within three business days of certification (the target median), keeps appealing power through signed evidence, is protected from one-shot clawbacks, and is not forced to change its software. It pays for a subscription only because it protects payroll — and pays its financing cost to the lender, not to BC.
Days, not months
Target: median ≤ 3 business days from certification to the advance landing. In the worked example the claim is filed 09:10, certified 10:42, drawn 11:05, credited the next day. Certification runs in under 5 seconds at p95 once documents agree.
Evidence wins appeals
Denial-prevention checks flag missing items before submission. If a deduction happens, an appeal is drafted from the signed record and the insurer's own verification view; the hospital owner reviews and submits.
Soft netting, never a clawback
Shortfalls are netted at a capped share (default 20%) over a rolling window (default 45 days) from future remittances, so one deduction cannot stop a salary run.
Works with paper and with HIS
Modern systems push fields by API; hospitals with no software photograph the bill and a named BC operator confirms the OCR. Same claim record either way.
Sign what you can read
Limit, rate, fee, tenor and netting rules are integers in the terms digest the hospital signs. A change is a new facility, not a silent edit.
Every number drills down
Cash advanced, outstanding, expected this week and "what is blocking money" — each figure resolves to the rows behind it. Unknown values show as unknown, never as zero.
What does it do to a hospital's cash? A calculator
Illustrative arithmetic, not a quote. Real rates are set by the lender in the facility terms. Financing cost shown is the lender's discount on the financed amount for the average wait; it excludes any per-advance fee and the optional BC revenue-cycle subscription (indicative ₹5,000–25,000 per month by bed count).
Before and after: the Sunrise claim
Real-world texture: for NHCX-integrated hospitals the government's DHIS scheme pays facilities an incentive per claim (₹200 or 10% of the claim, whichever is lower, capped at ₹1 crore, under the April–September 2026 corrigendum; it was ₹500 previously). BC's NHCX envelope work means a hospital that is already on BC is closer to qualifying for such incentives — a happy side-effect, not the core promise.
How does BC help patients carry their data when they change hospitals?
The patient holds a hospital-signed copy of their own record, encrypted on their phone, and decides who may read it. When Ramesh changes hospital, the new hospital sends a consent request; Ramesh approves exactly which records, for what purpose and for how long; the record is released directly under that consent; and Ramesh sees an access log. The record cannot be edited by the patient or by BC — which is precisely why the next hospital and the insurer can trust it.
The journey: Sunrise → Apex Cardiac Centre
Sunrise issues Ramesh's discharge summary as a FHIR record and signs it with its facility key. The record lands encrypted in the BC locker and on Ramesh's phone. Only a hash is anchored publicly.
Ramesh's cardiologist refers him to Apex Cardiac Centre. At admission, Apex's system raises a consent request through the ABDM consent manager: "prior cardiac history, last 24 months, for treatment, 30 days."
His phone shows purpose, scope and expiry in plain language. He approves (or narrows) it. The consent artefact is signed with his device key — silence or a pre-ticked box is never consent.
The record is released under that consent through ABDM's Fidelius-encrypted exchange. Apex sees verified prior history before filing its own pre-authorisation — no repeat tests, no photocopies.
Ramesh's access log shows who looked, when and under which consent. Day 31 the consent expires automatically; he can also revoke it in one tap. Revocation is terminal: it cannot be quietly undone.
Try it — build a consent
A teaching model of what the consent screen conveys: purpose limitation, narrow scope, a hard expiry, and an entry in the patient's access log. Under India's DPDP Act consent must be free, specific, informed, unambiguous and withdrawable.
Where each thing lives
| What | Issuing hospital | Patient's phone | BC servers | Transparency log | Next hospital / insurer |
|---|---|---|---|---|---|
| Clinical record (readable) | Yes | Yes — encrypted | Never | Never | Only within the consent window and scope |
| Ciphertext + signed hash | — | Yes | Yes | Hash only | — |
| Consent artefact | Copy | Signed here | Verified and enforced | Hash | Copy |
| Money | Bank account | — | Never | Never | Bank / escrow |
| TOTAL held by BC in readable form: 0 clinical records · 0 record keys · ₹0 of anyone's money. | |||||
Common questions
Can I upload my own old reports?
No — deliberately. The locker is verified-only: every record is issued and signed by a registered facility, so the next hospital or insurer can rely on it without a further check. Corrections come from the hospital as superseding records; both versions remain visible.
What if I lose my phone?
You lose that device's copy, not your history. Because the hospital is the author and signer, the record can be re-issued from the hospital or the locker to a new device. (An optional escrow of the key under audited KMS control exists only as an explicit patient opt-in.)
What if I don't have ABHA or a smartphone app?
You receive an expiring link by SMS after discharge and can grant consent from a browser without creating an account.
Why trust a record I cannot edit?
That is the point. Patient-editable records are not accepted by insurers. The patient controls who may read, not what it says — the same split as a vaccination certificate.
Real-world precedent: India's CoWIN vaccination certificates (built on the DIVOC open-source stack) showed that more than two billion signed, holder-carried, tamper-evident health credentials can be issued and verified at national scale. The BC locker applies the same pattern to discharge summaries, bills and diagnostics. The backbone is real: as of 10 July 2026 India had 93.95 crore ABHA numbers, over 105 crore digital health records linked, 5.33 lakh registered facilities and 9.85 lakh registered professionals.
How many user types exist, and what does each do?
Six user populations and 16 roles. BC staff (operators), hospital people, lender people, insurer/TPA people, patients, and external auditors. The populations are disjoint by construction — a hospital administrator can never grant themselves, or anyone, a BC-operator or lender role, because no table, join or code path connects them. That separation is what makes four-eyes controls real instead of decorative.
BC's own workforce, provisioned out-of-band (never self-service). Sign in with passkeys (WebAuthn); every privileged act re-checks the role against the grant table, so a revoked operator cannot finish an action with an old session. Role names are indicative of the functions in the BRD.
Onboarding maker
Prepares a hospital's, lender's or insurer's application with KYC (PAN, GSTIN, registration, bank account, authorised signatory).
Onboarding checker
A different person who approves. A database check forbids checker = maker. Approval creates the tenant and first admin in one transaction.
HITL desk reviewer
"Human in the loop": confirms figures that OCR extracted from photographed bills against the images, inside a 4-hour SLA, with countdown timers.
Verifier
Samples certified claims for review; high-risk bands surface first. Also approves regulated-capability switches under maker-checker.
A hospital is a tenant. Its people sign in with a one-time email code (hospital code + email). Everyone sees only their own hospital's data.
Owner / authorised signatory
Dr Joshi at Sunrise: sees cash advanced, outstanding and expected this week; signs facility offers; co-signs where terms require. First thing on the screen: what is blocking money?
Billing executive
Files claims, fixes rejections, uploads missing documents, issues signed records at the bedside. Sorted by money at risk, oldest first.
Hospital finance
Tracks repayments due, deductions taken and reconciliation breaks. Sorted by due date.
Tenant admin
Invites, activates and suspends staff and grants roles within the hospital only. Cannot grant a role to themselves (table constraint), cannot create a lender role, cannot touch KYC, and cannot read clinical records — "she administers people, not records." A tenant can never have zero admins.
A third identity population, created by BC operators under four-eyes, keyed on the lender. They sign in naming their lender code (e.g. DECCAN) and see only their own book.
Credit officer
Countersigns or declines facilities; sees limit, drawn, outstanding, headroom, exposure by hospital; releases hard stops — the only role that can.
Lender operations
Handles disbursement instructions, settlements received and repayments confirmed against the bank feed.
Lender risk & audit
Watches variance trend, payer concentration, reserve and breach proximity; drills every figure down to its rows.
Added by amendment: insurers and TPAs are a PAYER tenant kind (IRDAI registration in place of a clinical-establishment registration). Visibility rule: a payer sees only claims it is party to, its own verification events, its own settlement/deduction record and its own variance profile — never another payer's, never a hospital's other claims, never lender pricing.
Payer admin
Manages the payer's own members and roles, like a hospital's tenant admin.
Claims verifier
Kavita at MedAssist: opens a time-boxed, claim-scoped view of the signed record and checks signature + anchor. The patient sees that she looked.
Payer finance
Settles to the collection account, tracks deductions and responds to disputed ones inside the platform instead of by email.
Signs in with ABHA; BC issues no patient credential and stores no password. Holds only an ABHA address, linked claim and record references, and a public key.
What Ramesh can do
- Read his signed records (they sit encrypted on his phone)
- Grant, narrow or revoke consent in one tap
- See every rupee approved, paid and deducted — with the reason
- See who accessed his record and when
What Ramesh cannot do
- Edit or upload records (verified-only locker)
- Be listed or searched by anyone — no route lists patients
- No-ABHA patients use an expiring SMS link instead
No standing login. An external auditor (internal audit, regulator's representative, bank's reviewer) receives a scoped, expiring, read-only credential. Because ledgers are hash-chained and anchored, an auditor can walk from a rupee in escrow back to the signature on a discharge summary and independently verify nothing was altered.
| Population | Roles | Sign-in | Sees |
|---|---|---|---|
| BC operators | 4 | Passkey | Cross-tenant operational desks; no clinical content |
| Hospital | 4 | One-time email code | Own hospital only |
| Lender | 3 | One-time email code (lender code) | Own book only |
| Insurer / TPA | 3 | One-time email code | Own claims, own verification events, own variance |
| Patient | 1 | ABHA (or expiring SMS link) | Own record and log |
| Auditor | 1 | Scoped expiring credential | Read-only, scoped |
| TOTAL: 6 populations · 16 roles · 1 role-routed sign-in surface · 0 passwords stored anywhere | |||
FJA697MJHA) the tenant-admin and owner/signatory roles are held by different seeded users; check the seed rather than assuming one person holds both.What is the market size in India?
Every insured discharge in India is a potential claim event on the BC rail. In FY25 insurers paid ₹94,248 crore on 3.26 crore claims; about two-thirds of that value (≈ ₹62,500 crore) is cashless — money hospitals wait to receive. Depending on the days of delay, ₹5,000–15,000 crore of cashless claims is outstanding at any moment. BC's revenue pool (financing take rate plus verification fees) is a few hundred crore a year at full theoretical adoption; the founders' own base case reaches about ₹56 crore of revenue by FY2031-32.
TAM · SAM · SOM, in plain terms
| Definition | Size | Basis | |
|---|---|---|---|
| TAM | Paid claims that could be financed or verified each year | ≈ ₹94,000 cr paid claims; 3.26 cr verification events | IRDAI FY25 (via IndiaMedToday); verification fee pool at ₹50–150 each = ₹160–490 cr/yr (founders' pricing) |
| SAM | Private hospitals under 100 beds on NHCX — the segment no bank serves today | ≈ 46,000 facilities | Founders' estimate from NHA/PIB data; to be verified before bank use |
| SOM | Founders' design point | 1 lakh claims/month across 10,000 hospitals ≈ ₹2,400 cr advanced/yr | Planning assumption |
| TOTAL claim value in play: ₹94,248 cr/yr · of which cashless ≈ ₹62,500 cr/yr (derived: 66.35% × ₹94,248 cr). | |||
Size the opportunity yourself
Derived from FY25 IRDAI-reported totals (₹94,248 cr paid; 66.35% cashless; 3.26 cr claims). Cashless pool × days ÷ 365 approximates the amount outstanding at any moment. This is a ceiling for sizing, not a forecast: it assumes every claim is financeable and every payer verifies.
The founders' base case (five-year financial model)
| ₹ lakh unless stated | FY27-28 | FY28-29 | FY29-30 | FY30-31 | FY31-32 |
|---|---|---|---|---|---|
| Hospitals live (closing) | 20 | 150 | 600 | 1,800 | 4,000 |
| Gross amount advanced | 454 | 5,245 | 28,032 | 103,007 | 263,869 |
| Revenue: financing take rate | 1.8 | 22 | 126 | 464 | 1,187 |
| Revenue: verified record fee | 0.6 | 13 | 85 | 328 | 888 |
| Revenue: hospital subscription | 6.0 | 66 | 338 | 1,224 | 3,132 |
| Revenue: analytics licences | 0 | 0 | 50 | 150 | 375 |
| TOTAL revenue | 8.4 | 101 | 598 | 2,166 | 5,583 |
Management-judgement ramps, to be replaced with pilot data. FY31-32 advanced ≈ ₹2,639 crore is about 4% of the cashless pool — consistent with the SOM above. The raise sought is US$1.5 million pre-seed on a post-money SAFE.
Who else is in the space
| Company | What it does | Overlap with BC |
|---|---|---|
| HealthCRED | Cashless-receivables financing for small/mid hospitals (reported ~US$1.2M seed from Antler, 2025) | The lending seat — a potential participant on the rail |
| iCReDS | Health-finance infrastructure; won the NHA's NHCX Ideathon in 2026 | Adjacent infrastructure |
| KredX | Invoice discounting | General receivables, not health-specific evidence |
| Vitraya · ClaimBuddy | Claims-processing technology · claim assistance | Adjacent: tooling, not evidence or finance |
| Eka Care | Consumer personal health record | Holds patient-uploaded records not bound to claims |
| TOTAL: BC does not claim to be first; it claims to own the evidence layer others lend or process on top of. | ||
Back-of-envelope with real numbers: a 40-bed hospital billing ₹1.2 crore a month on cashless claims with a 60-day average wait has roughly ₹2.4 crore outstanding. At an 88% advance rate, ₹2.1 crore of working capital is unlocked — equal to many months of salaries for that hospital. Multiply by thousands of similar hospitals and you see why the pool is large even though each hospital is small.
Why is 2026 the relevant time?
2026 is not the year the idea got clever; it is the first year it became buildable honestly. Four public rails — identity (ABDM), claims exchange (NHCX), privacy (DPDP) and digital lending (RBI) — matured within about 24 months, and insurers now face real clocks for cashless decisions. Before this, a platform like BC would have had to build all four itself, or lean on private promises no bank could underwrite. The window has also opened for everybody, so the advantage goes to whoever builds it properly and early.
IRDAI Master Circular: insurers must answer cashless pre-authorisation within one hour and give final discharge approval within three hours; delay costs are borne from shareholders' funds. Authorisation stopped being the bottleneck — the money after approval is.
NHCX goes live as one of ABDM's three gateways. Insurers and TPAs and hospitals can exchange claims on a single FHIR wire. (Project research cites 83 payers, 42,687 facilities and 23.4M claims; an independent mid-2024 source cited 34 payers live — see the caveat below.)
Policy and regulation reset: RBI's Digital Lending Directions 2025 and Co-Lending Directions 2025 set a written non-custodial lending-service-provider standard; DPDP Rules 2025 defined consent and consent managers; GST was removed from life and health premiums and foreign ownership of insurers opened up — pushing health cover wider.
ABDM at scale: 93.95 crore ABHA numbers, 105+ crore linked records, 5.33 lakh facilities. NHA's DHIS incentives now require ABDM v3 milestones (M1–M3) from July 2026 — a push for hospital software to modernise.
Registered DPDP consent managers become operational (per project regulatory research). Consent becomes enforceable infrastructure rather than a checkbox — exactly what a patient-held record needs.
The ground has stopped moving, but competitors have noticed: a funded receivables lender (HealthCRED, 2025 seed) and an NHCX-linked infrastructure player (iCReDS, 2026 ideathon winner) are already in the market. BC's bet is that the evidence layer, not the capital, is the durable position.
Why not earlier — and why not later?
Nothing to stand on
No national health ID at scale, no common claims wire, no consent framework, no non-custodial lending standard. A startup would have had to invent trust bilaterally with every hospital, insurer and bank.
The rails will be crowded
Once the public rails are mature, lenders and insurers will have picked partners, and certifications (ABDM M1–M3, CERT-In audit, NHA agreements) take 20–43 weeks from incorporation — the longest clock on the programme, and the moat.
Build status, honestly
A clear guide should separate what is designed from what is built from what is proven on live money. As of 9 October 2026:
| Sprint | Completion | Meaning |
|---|---|---|
| Sprints 1–8 | 100% | Closed on master and gated |
| Sprint 9 | ~97% | Built and gated once; reopened for a few late slices and a final full gate |
| Sprint 10 | 0% | Specification (Oracle) written and queued to land |
| Sprint 11 | 0% | Not started |
| TOTAL | ~64% | About 76 of ~120 build slices; slice counts are a progress indicator, not a promise of calendar time |
- Built (as of the 1 Oct 2026 snapshot): 11 services, 156 API operations, 124 migrations, 51 routed screens covering the platform spine, onboarding, sign-in, claim capture with a human-review desk, certification, financing, consent core and anchoring service. Later sprints extended these.
- Not yet true: no live disbursement has happened; no ABDM, NHCX or CERT-In certification has been granted; no bank agreement is countersigned; no hospital is live; the mobile apps and ABDM integrations are gated on external steps.
- Rule of thumb for any statement in this guide: "designed" means in the BRD/SDD; "built" means gated code exists; "proven" means it has run on live money — nothing is in that third bucket yet.
Glossary
Sources and caveats
External sources used for statistics
- IndiaMedToday — record health-insurance claims settled in FY25 (IRDAI annual-report figures: 3.26 cr claims, ₹94,248 cr payouts, ~87% settled, ~8% repudiated, 66.35% cashless).
- GKToday — ABDM crosses 93.95 crore ABHA numbers (105 crore records, 5.33 lakh facilities, 9.85 lakh professionals; 10 Jul 2026).
- Nirmitee — Is NHCX mandatory in 2026? (vendor blog; NHCX status, DHIS incentive corrigendum, 34 payers live in Jul 2024).
- GKToday — IRDAI guidelines for faster claims (1-hour pre-auth, 3-hour discharge approval).
- Outlook Money — Economic Survey 2025-26 on insurance (₹11.9 lakh cr total premiums FY25; GST removal; foreign-ownership change).
Internal sources
Bridge Cure BRD v1.1 and SDD v1.1; investor deck v2 content; five-year financial model summary; the patient-owned health-record business case (18 Sep 2026); the tenant-administration and auth-and-mobile rulings; the execution plan; the brand decision (21 Sep 2026). All characters (Sunrise Hospital, Ramesh, Dr Joshi, Suresh, Kavita, MedAssist, Deccan Finance, Apex Cardiac Centre, Bharat Suraksha) are fictional.
Caveats
- Market figures are secondary-source and directional; verify against IRDAI, NHA and PIB primary publications before using them with a bank or investor.
- Derived numbers (cashless pool ≈ ₹62,500 cr, outstanding float, revenue ceilings) are arithmetic on those inputs, not published statistics.
- Unit economics (8% → 5% variance; 80% → 88% advance rate) are founders' assumptions pending pilot data.
- This guide describes a product and is not legal, financial or investment advice.