LID lifecycle

A single user can have LAMF and LAS in many shapes. Each unique loan application is identified by a lid. Based on the user's overall credit portfolio managed by Unity, these lids can either be independent or linked to each other.

Common scenarios

One LAMF loan application - one lid

1. With SIB, there can only be one DISBURSED loan at a time.
2. Topups can be applied on top of DISBURSED applications.

One LAMF and one LAS loan application - two lids

Since SIB is the only lender, a user's LAS and LAMF applications are always with the same lender.

1. When both applications are in PRE-SUBMITTED state - these are sibling lids
2. When one application gets SUBMITTED, one remains PRE-SUBMITTED - parent-child relationship is established between lids
3. When both lids are SUBMITTED - the parent lid is CLOSED, the child becomes ACTIVE . (Refer the previous section - there can only be one DISBURSED loan at a time)

LAMF Topup over ACTIVE LAMF - 2 lids

1. Parent-child relationship between lids.
2. Topups are allowed for the same asset class.
3. When the topup lid is SUBMITTED - the parent lid is CLOSED, the child becomes ACTIVE . (Refer the previous section - there can only be one DISBURSED loan at a time)

... and so on.

What's expected from the partner?

The Combined Credit Snapshot API response shows you which shape applies right now.

You should not attempt to build/replicate LID transitions logic on your backend. All transitions happen server-side on Unity. Your can read the current state, if required.