LID Lifecycle & Loan Relationships

LID lifecycle

A single user can have LAMF + LAS in many shapes (one only, both active, sibling, parent-child). The Combined Credit Snapshot response shows you which shape applies right now.

You never own LID transitions. PRE_SUBMITTED → SUBMITTED → DISBURSED → CLOSED, sibling → parent-child, top-up creation — all happen server-side. Your job is to read.

(no LID yet) ──▶ PRE_SUBMITTED ──▶ SUBMITTED ──▶ DISBURSED ──▶ CLOSED

Field	What it means
`loanStatus`	The journey marker you render: `PRE_SUBMITTED`, `SUBMITTED`, `DISBURSED`, `CLOSED`.
`status`	Internal book-keeping flag: `ACTIVE`, `INACTIVE`, `CLOSED`, `ARCHIVED`. Partners can mostly ignore.

Where they differ:

A CLOSED loanStatus always implies CLOSED status.
An existing ACTIVE loan flips to INACTIVE when its top-up child gets disbursed.

Sibling vs parent-child

There are two distinct patterns. Both are server-managed; the Combined Credit Snapshot reflects the current pattern.

Same-asset top-up (e.g. LAMF over LAMF)

parent: DISBURSED LAMF                     child: PRE_SUBMITTED LAMF top-up
┌────────────────────────┐  parentLoan ◀── ┌──────────────────────────────────┐
│ lid:   p1              │                 │ lid:   c1                        │
│ status: ACTIVE         │                 │ status: ACTIVE                   │
│ loanStatus: DISBURSED  │                 │ loanStatus: PRE_SUBMITTED        │
│ isDefault: true        │                 │ purpose: LOAN_APPLICATION:TOP_UP │
└────────────────────────┘                 └──────────────────────────────────┘

The parent-child link is established at top-up creation, before submission. The child appears in the parent's loanSummary.topUpLoans[] immediately with topUpStatus: IN_PROGRESS. When the child gets DISBURSED, it becomes the new servicing dashboard owner; the old parent flips to status: INACTIVE and topUpStatus: APPLIED.

Cross-asset (LAMF + LAS, same lender)

When a user has a LAMF and starts a LAS application (or vice versa), the two loans are siblings while both are PRE_SUBMITTED — not parent-child.

sibling A: PRE_SUBMITTED LAMF             sibling B: PRE_SUBMITTED LAS
┌───────────────────────────┐             ┌───────────────────────────┐
│ assetType: MUTUALFUND     │             │ assetType: STOCKS         │
│ loanStatus: PRE_SUBMITTED │             │ loanStatus: PRE_SUBMITTED │
│ purpose: LOAN_APPLICATION │             │ purpose: LOAN_APPLICATION │
└───────────────────────────┘             └───────────────────────────┘

The instant one of the two is SUBMITTED, the server flips the relationship to parent-child:

parent: SUBMITTED/DISBURSED LAMF          child: PRE_SUBMITTED/SUBMITTED LAS
┌────────────────────────┐  parentLoan ◀── ┌──────────────────────────────────┐
│ loanStatus: SUBMITTED  │                 │ loanStatus: PRE_SUBMITTED        │
│   or DISBURSED         │                 │   or SUBMITTED                   │
│ isDefault: true        │                 │ purpose: LOAN_APPLICATION:TOP_UP │
└────────────────────────┘                 └──────────────────────────────────┘

The child now shows up in the parent's loanSummary.topUpLoans[] (once servicing is active for the parent — i.e. once it's DISBURSED).

How partners detect each pattern from the snapshot

Pattern	Detection rule
Sibling	Two loans, same lender, both `loanStatus: PRE_SUBMITTED`, different `assetType`, both `purpose: LOAN_APPLICATION`.
Parent-child	Parent is in `topUpLoans[]` of the other loan's `loanSummary`, OR child has `purpose: LOAN_APPLICATION:TOP_UP` while a same-lender `DISBURSED` loan exists.

Scenario matrix

What partners should expect in each end-state, and what to render.

Scenario	`user.loans`	`topUpLoans[]`	Partner UI
LAMF only (DISBURSED)	1 entry: ACTIVE, MF, DISBURSED, `isDefault: true`	Placeholders, both `NOT_INITIATED`	LAMF servicing card. Surface "Add LAS" if `nudges.topup` includes `"las"`.
LAMF over LAMF	Parent DISBURSED + child PRE_SUBMITTED with `purpose: LOAN_APPLICATION:TOP_UP`	MF child `IN_PROGRESS`, STOCKS placeholder	Servicing card with "Top-up in progress" badge.
LAS only (DISBURSED)	1 entry: ACTIVE, STOCKS, DISBURSED, `isDefault: true`	Placeholders	LAS servicing card. Surface "Add LAMF" if nudge.
LAS over LAMF (cross-asset child)	LAMF DISBURSED parent + LAS child	LAS in LAMF's `topUpLoans` with `APPLIED`	LAMF servicing + "LAS in progress" card.
LAMF over LAS (cross-asset child)	Mirror of above	LAMF in LAS's `topUpLoans`	LAS servicing + LAMF in-progress card.
LAS + LAMF in parallel (siblings)	Both PRE_SUBMITTED, different assetType, same lender	No `loanSummary` (neither disbursed)	Two in-progress application cards.
LAS over LAS	Coming soon. Not yet supported.	—	Not yet applicable.

Known limitations

The child loan does not carry a back-pointer (parentLid) to its parent. Partners derive the relationship from the parent's topUpLoans[] or from the child's purpose: LOAN_APPLICATION:TOP_UP marker.
Sibling loans are not annotated with siblingLid in the response. Detect them from response shape.
For EIMPL loans, loanDetails[].loanSummary will be null because EIMPL has no servicing dashboard endpoint exposed today.