diff --git a/docs/MFL/LAP/Disbursement module/Deductions.md b/docs/MFL/LAP/Disbursement module/Deductions.md
new file mode 100644
index 00000000..af2751b8
--- /dev/null
+++ b/docs/MFL/LAP/Disbursement module/Deductions.md
@@ -0,0 +1,90 @@
+Deductions Logic
+
+
+
+
+ | Deduction Type |
+ Deduction Amount (Value / Formula / Logic) |
+ When Applicable |
+ When Adjusted |
+
+
+
+
+ | Processing Fee |
+
+ PF Amount = {(Loan Amount × (PF % / 100)) × 1.18}
+ Amount inclusive of 18% GST
+ PF % entered by BCM in Loan Offer module
+ |
+ All loans |
+ At disbursal |
+
+
+ | E-stamp Charge |
+
+ ₹38 (if agreement signing done online)
+ ₹0 (if agreement signing done offline)
+ |
+ Only when agreement signing done online |
+ At disbursal |
+
+
+ | Insurance Charges |
+ Total insurance premium (inclusive of 18% GST) |
+ All loans |
+ At disbursal |
+
+
+ | Stamp Duty |
+
+ State-based charge (refer state-wise stamp duty master)
+ ₹0 (if agreement signing done offline)
+ Note: State is derived from branch details of the RO who punched the case
+ |
+ Only when agreement signing done online |
+ At disbursal |
+
+
+ | CERSAI Charge |
+
+ ₹118 (if sanctioned loan amount > ₹5 lakhs)
+ ₹59 (if sanctioned loan amount ≤ ₹5 lakhs)
+ |
+ All loans |
+ At disbursal |
+
+
+ | Initial Login Fee |
+
+ ₹1,180 (IMD amount – currently constant)
+ Collected upfront during customer journey
+ |
+ All loans |
+ Not adjusted from disbursal |
+
+
+ | Login Fee Deductible |
+
+ ₹4,720 (if sanctioned loan amount > ₹10 lakhs – constant)
+ ₹2,950 (if sanctioned loan amount ≤ ₹10 lakhs – constant)
+ |
+ All loans |
+ At disbursal |
+
+
+
+
+All amounts mentioned are in Indian Rupees (₹).
+
+Important Notes
+
+ - Broken Period Interest (BPI) is not treated as a deduction in LOS.
+ - BPI is not shown in deduction summary and is excluded from Net Payment Amount calculation.
+ - BPI is not sent to LMS createLoan API under disbursal charge details.
+ - Deductions are not deducted from first tranche or first split payment.
+ - Deductions are applied on Sanctioned Loan Amount to derive Net Payment Amount.
+ - CO enters tranche amounts based on Net Payment Amount.
+ - Sum of all tranche amounts must equal Net Payment Amount (logic change pending implementation).
+ - Deduction charge details passed in LMS createLoan API are used by LMS to credit the total deduction amount to MFL bank account at disbursal.
+
diff --git a/docs/MFL/LAP/Disbursement module/Disbursal ready stage: 1st tranche.md b/docs/MFL/LAP/Disbursement module/Disbursal ready stage: 1st tranche.md
new file mode 100644
index 00000000..aec5fbcb
--- /dev/null
+++ b/docs/MFL/LAP/Disbursement module/Disbursal ready stage: 1st tranche.md
@@ -0,0 +1,111 @@
+Disbursal Ready Stage: CO
+
+
+ - Application in Ready for Disbursal stage is auto-assigned to the same CO who forwards the case from Loan Sanctioned stage and reflects in that CO’s queue.
+ - Net Payment Amount = Sanctioned Loan Amount − Total Deductions (refer separate product note on deductions).
+
+
+Disbursement Request Creation
+
+ - CO can create a disbursement request in the Ready for Disbursal stage based on Net Payment Amount.
+ - Single Tranche: Tranche amount is auto-populated and equals Net Payment Amount.
+ - Multi Tranche:
+
+ - CO enters tranche amount.
+ - Each tranche amount must be ≤ Net Payment Amount.
+ - Sum of all tranche amounts must equal Net Payment Amount.
+
+
+ - CO can select only the current date as disbursement date. Past or future dates are not allowed.
+
+
+Payment Details
+
+ - CO selects payment type:
+
+ - Single Payment Advice
+ - Multiple Payment Advice (Split Payments)
+
+
+ - For single payment advice, amount is auto-set as tranche amount.
+ - For multiple payment advice, sum of all split payments must equal tranche amount.
+ - Allowed payment modes:
+
+ - Electronic Fund Transfer (NEFT / RTGS)
+ - Cheque
+
+
+ - For EFT:
+
+ - Payment < 2 lakhs → NEFT only
+ - Payment ≥ 2 lakhs → RTGS only
+ - Sub-mode auto-selected based on amount
+ - Ops selects one customer bank account (currently only penny-drop verified account available)
+
+
+ - For Cheque:
+
+ - Ops enters “In Favour Of” details
+ - No bank account details collected
+ - Penny-drop account number is passed to LMS createLoan API
+
+
+ - Since penny drop is performed on only one account, the same account is used for all split payments and passed to LMS.
+
+
+
+ - Disbursement request creates a disbursement task. Application stage remains Ready for Disbursal until tranche is disbursed.
+ - After disbursement:
+
+ - Single tranche → Application moves to Fully Disbursed
+ - Multi tranche → Application moves to Partially Disbursed
+
+
+ - CO can edit or delete the disbursement request as long as the task is in CO’s queue.
+ - CO cannot create another disbursement request if an active disbursement request exists.
+ - CO can send the disbursement task to BPO.
+
+
+
+
+Disbursal Ready Stage: BPO
+
+
+ - Disbursement task appears in BPO pool.
+ - BPO Manager can self-assign or assign the task to BPO child users.
+ - BPO child users can only self-assign the task.
+ - BPO completes checklist questionnaires under:
+
+ - Primary Verifications tab
+ - Checklist tab
+
+
+ - BPO can send the task to Ops. Hard stop applies if checklist is incomplete.
+ - BPO can send the task back to CO.
+
+
+
+
+Disbursal Ready Stage: Ops
+
+
+ - Disbursement task appears in Ops pool and must be self-assigned.
+ - Ops completes checklist questionnaires under:
+
+ - Primary Verifications tab
+ - Checklist tab
+
+
+ - Ops can edit disbursement date:
+
+ - Allowed dates: T, T-1, T-2
+ - If CO-selected date is older than T-2, Ops must reselect
+
+
+ - Selected disbursement date must be ≤ LMS business date. FinBox validates this.
+ - If LMS date validation fails, disbursal reverts to un-initiated state with Ops access restored.
+ - Ops approves the disbursement task to trigger LMS handoff.
+ - Tranche is marked Disbursed once APIs up to Process Instrumentation succeed and LAN is generated.
+ - Document upload failures do not block disbursement. Ops handles document upload later in LMS.
+ - Ops can send the task back to CO or BPO.
+
diff --git a/docs/MFL/LAP/Disbursement module/Fully disbursed.md b/docs/MFL/LAP/Disbursement module/Fully disbursed.md
new file mode 100644
index 00000000..e89cc8d8
--- /dev/null
+++ b/docs/MFL/LAP/Disbursement module/Fully disbursed.md
@@ -0,0 +1 @@
+Fully disbursed cases appear in the All cases tab for all users.
diff --git a/docs/MFL/LAP/Disbursement module/LMSHandoff.md b/docs/MFL/LAP/Disbursement module/LMSHandoff.md
new file mode 100644
index 00000000..7a4cb3fc
--- /dev/null
+++ b/docs/MFL/LAP/Disbursement module/LMSHandoff.md
@@ -0,0 +1,109 @@
+LMS Handoff
+
+First Tranche
+
+
+ - Ops user has to ‘approve disbursement’ for the active tranche to initiate the LMS handoff on disbursement tab
+
+
+Pre-checks/validations
+
+Pre-checks/validations run on LMS handoff initiation for the first tranche. If any pre-check fails, LMS handoff is blocked:
+
+
+
+ - All sanction conditions should be approved by Ops
+ - Ops checklist should be completed
+ - Disbursement date should be less than or equal to the LMS business date
+ - UCIC should be present for all applicant/co-applicants (fetched from PAN or mobile)
+ - “isNPA” flag should be false for all applicant and co-applicants
+ - IFSC code should be present in the Bank master
+ - Pincode should be present in the Pincode master
+
+
+LMS handoff APIs (First Tranche)
+
+LMS handoff for first tranche initiates the below series of APIs in the following order:
+
+
+
+ - Create Customer - for primary applicant and all co-applicants
+ - Process Receipt - For IMD details - This will be moved to journey now just after IMD is paid and not in the disbursal workflow
+ - Create Collateral
+ - Book Loan
+ - Process Instrumentation - For NACH details
+ - Create Document - Series of 4 APIs
+
+
+LMS Workflow Status
+
+After LMS handoff is initiated, Ops user gets an option to “check status” of the LMS workflow. List of possible statuses:
+
+
+
+ - “Payment initiated” - When LMS workflow initiated but status not fetched
+ - “Failed” - When any any pre-checks fails or any API out of the following fail: createCustomerAPI, createCollateral, bookLoan
+ - “Documents pending” - This is a substatus - When first 5 APIs are successful (till Process instrumentation) and Create Document API is in progress (this API might take some time, depends on number of documents)
+ - “Document failure” - This is a substatus - When Create Document API fails
+ - “Disbursed” - When createCustomer, createCollateral, bookLoan APIs are successful. System doesn't wait for the status of NACH API or createDocument API
+
+
+Retrigger Logic
+
+
+ - Ops user gets an option to retrigger LMS handoff (“retrigger disbursement” button) if the status is “failed”
+ - Retrigger option resumes the LMS workflow from the API which last failed
+ - Currently there is no option to retrigger from UI if either of NACH/Document APIs fail i.e. after the status of tranche is "Disbursed. Functionality to be added
+ - If Create Document API fails due to any document, rest other documents are uploaded
+
+
+
+If LMS handoff is re-triggered in failure scenarios, following pre-checks are re-run:
+
+
+
+ - Disbursement date should be less than or equal to the LMS business date
+ - UCIC should be present for all applicant/co-applicants (fetched from PAN or mobile)
+ - “isNPA” flag should be false for all applicant and co-applicants
+
+
+
+
+Second / Subsequent Tranche
+
+Pre-checks/validations
+
+Pre-checks/validations run on initiating LMS handoff for second/subsequent tranches:
+
+
+
+ - Disbursement date should be less than or equal to the LMS business date
+
+
+LMS handoff APIs (Second / Subsequent Tranche)
+
+
+LMS Workflow Status
+
+List of the possible statuses of the LMS handoff for second/subsequent tranches:
+
+
+
+
+Retrigger Logic
+
+ - Ops user gets an option to retrigger LMS handoff for second/subsequent tranches if the status is “failed”
+
+
+
+If LMS handoff is re-triggered in case of failure for second/subsequent tranches, following pre-checks are re-run:
+
+
+
+ - Disbursement date should be less than or equal to the LMS business date
+
diff --git a/docs/MFL/LAP/Disbursement module/artially Disbursed: Subsequent Tranches.md b/docs/MFL/LAP/Disbursement module/artially Disbursed: Subsequent Tranches.md
new file mode 100644
index 00000000..1f07abbe
--- /dev/null
+++ b/docs/MFL/LAP/Disbursement module/artially Disbursed: Subsequent Tranches.md
@@ -0,0 +1,34 @@
+Partially Disbursed: Subsequent Tranches
+
+Partially Disbursed Stage: CO
+
+ - CO can locate a partially disbursed case from the All cases tab.
+ - CO can create a new disbursement request directly from All cases. No case or task assignment is required.
+ -
+ Pending Balance =
+ {Net Payment Amount − Sum of all previously disbursed tranche amounts}
+
+ - CO creates the disbursement request based on the pending balance.
+ - Tranche amount cannot exceed the pending balance.
+ - Disbursement date, payment mode, and split payment logic are the same as the Ready for Disbursal stage.
+ - Tranche editing, deletion, and movement are allowed only for the active tranche.
+ - These actions are permitted only while the disbursement task is in the CO’s queue.
+
+
+Partially Disbursed Stage: BPO
+
+ - BPO receives a new BPO checklist questionnaire on the Primary Verifications tab for the active tranche.
+ - BPO checklist questionnaires for previous tranches remain in Completed state and are non-editable.
+ - BPO receives a new BPO checklist on the Checklist tab for the active tranche.
+ - Checklists for previous tranches remain completed and non-editable.
+ - Disbursement task movement to Ops or send-back to CO follows the same logic as the Ready for Disbursal stage.
+
+
+Partially Disbursed Stage: Ops
+
+ - Ops receives a new Ops checklist questionnaire on the Primary Verifications tab for the active tranche.
+ - Checklist questionnaires for previous tranches remain completed and non-editable.
+ - Ops receives a new Ops checklist on the Checklist tab for the active tranche.
+ - Ops checklists for previous tranches remain completed and non-editable.
+ - Disbursement date editing rules, LMS handoff trigger logic, and send-back flow to CO or BPO are the same as the Ready for Disbursal stage.
+
diff --git a/docs/MFL/LAP/Disbursement module/myqueue.md b/docs/MFL/LAP/Disbursement module/myqueue.md
new file mode 100644
index 00000000..6fe43e28
--- /dev/null
+++ b/docs/MFL/LAP/Disbursement module/myqueue.md
@@ -0,0 +1,57 @@
+My Queue Behaviour
+
+Disbursal Module: My Queue Policies
+
+Disbursal Ready Stage: CO
+
+ - CO can see the disbursal_ready application in My Queue.
+ - The main task in Disbursal Ready stage is auto-assigned to the same CO who forwarded the case from Loan Sanctioned stage.
+ - The disbursement task is automatically assigned to the same CO who creates the disbursement request.
+
+
+Disbursal Ready Stage: BPO
+
+ - BPO Manager and BPO Child users can see the disbursement task in their pool.
+ - BPO Manager can self-assign the task or assign it to any child user.
+ - BPO Child user can only self-assign the task and cannot assign it to others.
+ - BPO users do not get edit access unless they self-assign the task.
+
+
+Disbursal Ready Stage: Ops
+
+ - Ops user can see the disbursement task in their pool.
+ - Ops user must self-assign the task to edit anything.
+ - In Disbursement Triggered state, the task is auto-assigned to the same Ops user who had it in Pending on Ops state.
+ - In Disbursement Approved state, the task is unassigned from Ops and appears only in All Cases, not in My Queue or Pool.
+ - When the application state becomes Fully Disbursed or Partially Disbursed, the task is unassigned and appears in All Cases.
+
+
+Partially Disbursed Stage: CO
+
+ - CO can see the Partially Disbursed application in All Cases.
+ - CO can create a new tranche without assigning the disbursement task to themselves.
+ - Once the disbursement task is created, it is automatically assigned to the CO who created it and appears in that CO’s My Queue.
+
+
+Partially Disbursed Stage: BPO
+
+ - BPO Manager and BPO Child users can see the new or active disbursement task in their pool.
+ - BPO Manager can self-assign or assign the task to any child user.
+ - BPO Child user can only self-assign the task.
+ - BPO users have no edit access unless they self-assign the task.
+
+
+Partially Disbursed Stage: Ops
+
+ - Ops user can see the new or active disbursement task in their pool.
+ - Ops user must self-assign the task to edit anything.
+ - In Disbursement Triggered state, the task is auto-assigned to the same Ops user who had it in Pending on Ops state.
+ - In Disbursement Approved state, the task is unassigned and appears only in All Cases.
+ - When the application state becomes Fully Disbursed or Partially Disbursed, the task is unassigned and appears in All Cases.
+
+
+Fully Disbursed Stage
+
+ - Cases appear only in All Cases for all users.
+ - They do not appear in any user’s Pool or My Queue.
+
diff --git a/docs/MFL/LAP/In-Principle Sanction/OfferNegotiation.md b/docs/MFL/LAP/In-Principle Sanction/OfferNegotiation.md
new file mode 100644
index 00000000..bf0179f9
--- /dev/null
+++ b/docs/MFL/LAP/In-Principle Sanction/OfferNegotiation.md
@@ -0,0 +1,35 @@
+Offer Negotiation
+
+BBM negotiation will happen in parallel to legal and technical verification in the "In-principle sanctioned" stage. BBM can only edit PF and ROI and view other parameters of the negotiated offer.
+
+NOTE: It is not possible that the soft-sanctioned (in-principle) loan offer details will change after legal and technical verification are complete. The only inputs from these two will be ‘recommend’ or ‘do not recommend’. If one of these two decide ‘Not recommended’, BCM will raise a deviation separately.
+
+When BBM creates a negotiated offer, negotiation task flows to NSH for approval of negotiation once BBM submits. There is a validation that BBM cannot close the negotiation task before the NSH approves the negotiation task. Following will be the flow after NSH approves the negotiated PF and ROI:
+
+
+ - The negotiation task will move to BCM, where he can either close the negotiation task (which will end the negotiation module) or change the loan amount. Currently, BCM cannot set a new loan amount greater than the current loan amount.
+ - The BBM will share this new loan amount information with the customer. Post discussions, BBM can either:
+
+ - Accept and close the negotiation with the new loan amount set by the BCM, or
+ - Reject the new loan offer, which opens a new negotiation task for the BBM. This task has the new loan amount set by the BCM, but the PF and ROI are reset to the originally set parameters.
+
+
+ - With this new negotiation task, BBM can repeat the negotiation process, changing ROI and PF again, moving it for approval to NSH, and continuing the subsequent processes.
+ - If NSH rejects the BBM negotiated offer, the offer details will revert to the original in-principle offer approved by the BCM.
+
+
+It is possible that the case can be sent back in the negotiations stage. Two likely scenarios (not in the current scope):
+
+
+ - Customer requests an increased loan amount than in-principle and has additional documents to support the request. BBM will assign the task back to BCM, and BCM will send it back to the under-review stage.
+ - While negotiation is happening, legal might request additional docs or co-applicants to be added. BCM can send the case back to under review.
+
+
+Offer details will be reset in case of send-back. Loan application cancel and rejection options are provided to the BCM for scenarios where the customer no longer wants the loan or major issues are discovered with the application at this stage.
+
+RBAC rules for this stage:
+
+ - BCM can only edit loan amount and view other parameters of the negotiated offer.
+ - BBM can only edit PF and ROI and view other parameters of the negotiated offer.
+ - NSH can only view and approve or reject negotiation workflow, i.e., the negotiated offer proposal.
+
diff --git a/docs/MFL/LAP/In-Principle Sanction/Readme.md b/docs/MFL/LAP/In-Principle Sanction/Readme.md
new file mode 100644
index 00000000..156928da
--- /dev/null
+++ b/docs/MFL/LAP/In-Principle Sanction/Readme.md
@@ -0,0 +1,10 @@
+In-principle Sanctioned Stage
+
+Case reaches "In-principle sanctioned" stage when Credit sanctions the case. Parallel verifications like legal, technical, and RCU might or might not be completed by this time. This stage includes primarily the following activities:
+
+
+ - Completion of legal, technical, and RCU verifications is mandatory in this stage.
+ - Actual collateral details updation on Collateral tab by BCM after the technical verification is complete.
+ - Offer negotiation by BBM.
+ - Risk profiling (risk calculation) is mandatory by BCM in this stage, although BCM can also complete this in the Under review stage.
+
diff --git a/docs/MFL/LAP/Post-Sanction/Enach.md b/docs/MFL/LAP/Post-Sanction/Enach.md
new file mode 100644
index 00000000..64931557
--- /dev/null
+++ b/docs/MFL/LAP/Post-Sanction/Enach.md
@@ -0,0 +1,24 @@
+E-NACH
+
+E-NACH can be initiated by CO on the E-Registrations tab.
+
+E-NACH can be performed via two modes: Online & Offline
+
+Online NACH
+
+ - CO can initiate online NACH via dashboard.
+ - On initiation, CO gets the mandate link on the dashboard. In parallel, the customer receives an SMS with the E-NACH link from Digio.
+ - Customer or CO can open the link and complete the E-NACH process.
+ - Customer can see the bank account details verified from Penny drop.
+ - Customer can choose one of the following E-NACH set-up modes: Debit card, Net banking, or UPI.
+ - System waits for the webhook from Digio which updates the UMRN. Until this is received, the system blocks the user from moving forward. User is on wait screen.
+ - Once webhook is received, customer/CO receives a success confirmation.
+
+
+Offline NACH
+
+ - CO can initiate offline NACH via dashboard.
+ - CO gets a window where they can upload a proof (scanned copy of offline NACH) and input the UMRN number, both of which are mandatory.
+ - The UMRN details will be visible on the E-NACH sub-tab under E-Registrations.
+ - CO can edit the UMRN until the case moves to the next stage.
+
diff --git a/docs/MFL/LAP/Post-Sanction/Pennydrop.md b/docs/MFL/LAP/Post-Sanction/Pennydrop.md
new file mode 100644
index 00000000..49d9704a
--- /dev/null
+++ b/docs/MFL/LAP/Post-Sanction/Pennydrop.md
@@ -0,0 +1,13 @@
+Penny Drop
+
+CO can initiate Penny drop on the E-registrations tab. While initiating, CO gets an option to select one out of the bank accounts added in the application for applicant and co-applicants. Currently, the system only shows the bank accounts for the primary applicant. (Fix to be implemented)
+
+After selecting a bank account, CO has to re-enter the bank account number in a text field, with the last 4 digits validated against the account number extracted from the bank statement or the manually entered account number. The bank name is also validated along with the bank account number.
+
+Penny drop can be performed on only one account. The same account is used for E-NACH and money deposit after disbursal.
+
+Currently, Penny drop is done using Zoop service (to be moved to Digio).
+
+Currently, Penny drop can be initiated via the dashboard on a sidebar (journey screen). Planned improvements include bringing the whole experience to the dashboard for a seamless workflow.
+
+If Penny drop fails, CO can retry it on the sidebar. (User experience improvements for failure scenarios are planned)
diff --git a/docs/MFL/LAP/Post-Sanction/RCU Stage-2.md b/docs/MFL/LAP/Post-Sanction/RCU Stage-2.md
new file mode 100644
index 00000000..a842b76b
--- /dev/null
+++ b/docs/MFL/LAP/Post-Sanction/RCU Stage-2.md
@@ -0,0 +1,66 @@
+RCU Stage-2
+
+CO can initiate RCU Stage 2 – Document Vetting after the final sanction (“Loan Sanctioned” stage). This process enables the RCU team to verify the original collateral documents for authenticity.
+
+The CO can view the uninitiated “RCU Document Vetting” task in the Verifications tab → Other Verifications sub-tab.
+
+The RCU Document Vetting workflow follows this sequence: BCM → RCU Vendor → RCU Manager (State-level)
+
+Document Upload
+
+ - CO uploads the original collateral documents under the All Documents tab in the Collateral category. The CO may replace any previously uploaded photocopies or original documents.
+ - Document upload is optional at this stage; there is currently no system validation or hard stop to enforce mandatory collateral document uploads.
+ - The system does not restrict the CO from uploading documents in other categories, such as Financial or Address.
+
+
+Task Assignment
+
+ - After uploading the collateral documents, the CO assigns the vetting task to an RCU vendor to initiate document vetting. The CO selects the vendor from a list mapped to the respective state.
+ - Once the task is assigned, it appears in the queue of the respective RCU vendor.
+
+
+RCU Vendor Actions
+
+ - Screens the original collateral documents uploaded by the CO. (If no new documents are uploaded, screening is not required)
+ - Submits a decision on document vetting, optionally attaching a vetting report or supporting document.
+
+
+Document Screening Statuses
+
+ - Screened: Document is verified and approved
+ - Sampled: Requires further investigation
+ - Hold: Screening cannot be performed due to an issue
+ - Under Review: Default status indicating pending screening
+
+
+If any document is marked as Hold or remains in Under Review, the system does not allow the vendor to provide a final vetting decision or progress the task further.
+
+RCU Vendor Decision Options
+
+ - Positive
+ - Negative
+ - Could Not Verify
+ - Refer to Credit
+ - R-Doc
+ - R-Profile
+ - Hold: Sends the vetting task back to the CO to resolve queries. The task moves to the same CO’s queue, and the CO can resend it to the vendor after addressing the observations or adding clarifications/documents.
+
+
+Routing to State-level RCU Manager
+
+ - Once the RCU vendor submits a decision, the task is automatically routed to the State-level RCU Manager if either of the following conditions is met:
+
+ - At least one document is marked as Sampled, or
+ - The vendor’s decision is one of: Negative, Could Not Verify, Refer to Credit, R-Doc, or R-Profile
+
+
+ - If neither condition is met, the RCU vetting workflow ends after the vendor’s decision.
+ - If routed to the State-level RCU Manager, the manager can perform all actions that the vendor can, including screening documents and providing a final decision.
+ - The RCU manager can also override the vendor’s actions, such as changing document screening statuses or vetting decisions.
+ - The RCU manager does not have access to the Hold status when screening individual documents.
+ - The RCU manager can give the overall vetting decision as Hold to send the task back to the CO for clarification. Once the CO provides the required inputs, the task can be resent to the RCU manager for final review.
+
+
+After the RCU manager provides the final decision, the RCU vetting workflow concludes.
+
+Based on the final RCU decision, the CO can raise relevant RCU deviations in the Deviations Module.
diff --git a/docs/MFL/LAP/Post-Sanction/Readme.md b/docs/MFL/LAP/Post-Sanction/Readme.md
new file mode 100644
index 00000000..9ccd6562
--- /dev/null
+++ b/docs/MFL/LAP/Post-Sanction/Readme.md
@@ -0,0 +1,48 @@
+Post Sanction
+
+When the case is finally sanctioned, it moves from the "In-principle sanctioned" stage to the "Loan sanctioned" stage (Post sanction stage). The CO performs the following activities in this stage:
+
+
+ - Property Document Collection
+ - Insurance
+ - Pennydrop
+ - NACH
+ - Agreement (Emudra)
+ - RCU stage 2
+ - Closing out Sanction Conditions
+
+
+The CO will also check if all sanction conditions have been met and will mark each condition as complied, waived off, PDD, or OTC. Approvals for conditions marked as waived-off, PDD, or OTC must be done by the designated authority (as per MFL logic) before the case can move to the next stage.
+
+Key sequence and related validations:
+
+ - Insurance must be performed before Penny drop.
+ - Penny drop must be performed before E-NACH.
+ - E-NACH must be performed before E-signing.
+ - RCU stage 2 can be performed in parallel to the above activities but is mandatory in this stage.
+
+
+After the loan sanction state, the case will move to the Disbursal Ready state:
+
+ - CO can initiate disbursal.
+ - BPO2 can perform their checks.
+ - Ops can perform their checks.
+
+
+For multi-tranche disbursal:
+
+ - Once one tranche is disbursed, the case moves to Partially Disbursed, where CO, BPO2, and Ops can perform their tasks for subsequent tranches.
+
+
+For single tranche disbursal:
+
+ - The case moves directly to Disbursed state once completed.
+
+
+Once the entire loan disbursement is completed, the case moves to Disbursed state.
+
+For reporting and "My Queue" purposes, the case can be identified with a combination of task_type and task_state at any given point:
+
+ - For the first tranche, task_type will be Disbursal Ready and task_state will indicate the responsible party (CO, BPO2, Ops, etc.).
+ - For subsequent tranches, task_type will be Partially Disbursed and task_state will indicate the responsible party (CO, BPO2, Ops, etc.).
+
diff --git a/docs/MFL/LAP/Underwriting/CreditDeviations.md b/docs/MFL/LAP/Underwriting/CreditDeviations.md
new file mode 100644
index 00000000..96f103ea
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/CreditDeviations.md
@@ -0,0 +1,85 @@
+
+Credit Deviations
+
+
+The Loan Offer must be set before any deviation can be raised, as
+deviations are specific to each product type.
+(Reference: Credit Deviations Master attached in mail)
+
+
+General Rules
+
+ - Different LAP products have different sets of applicable deviations.
+ -
+ The authority required to approve a deviation depends on the LAP product and,
+ in some cases, the loan amount.
+
+ -
+ As per the Product Level Scheme Collateral Policy master:
+ Minimum permissible loan amount: ₹3 lakhs
+ Maximum permissible loan amount: ₹5 crores
+
+ -
+ The system prevents the BCM from entering an amount outside this range wherever
+ the loan offer amount can be set/edited.
+
+
+
+Deviation Flow by Stage
+
+ -
+ Under Review:
+
+ - Deviations can be raised by the BCM prior to initiating the DOA flow.
+ - If any deviation is pending or rejected, the current DOA assignee cannot
+ approve DOA or forward to next authority until all deviations are approved.
+
+
+ -
+ In-principle sanctioned:
+
+ - BCM can raise deviations as RCU verification decisions may come in this stage.
+ - Case movement is restricted until all open deviations are approved.
+
+
+ -
+ Loan sanctioned:
+
+ - Deviations can be raised by CO based on RCU Stage 2 document vetting decisions.
+ - Case movement blocked until all open deviations are approved.
+
+
+
+
+How to Raise a Deviation
+
+ - Select the deviation from the master list.
+ - Choose the relevant applicant or co-applicant.
+ - The deviation task is automatically assigned to the specified approval authority (e.g., SCM).
+ - Currently, if multiple SCMs exist in a state, tasks are not sent to a shared pool.
+ - All deviations are manually initiated; automatic deviations are not yet implemented.
+
+
+Approval Rules
+
+ -
+ Approval authority and any higher authority in the hierarchy can approve deviations
+ in their queue.
+
+ -
+ Example: If two deviations are raised, one assigned to a ZCM and another to NCM:
+ NCM can approve both, but ZCM can approve only the one assigned to them.
+
+
+
+Restrictions and Constraints
+
+ - Pending deviations can be deleted by the user who raised them until approved/rejected.
+ - Once approved or rejected, deviations cannot be deleted or re-evaluated.
+ - Duplicate deviations for the same applicant cannot be raised.
+ -
+ If the BCM changes the LAP product after raising a deviation, the same type can
+ be raised again. Deviations from the previous product can be deleted if still pending.
+
+ - The system does not auto-delete deviations when the LAP product changes.
+
diff --git a/docs/MFL/LAP/Underwriting/DOA.md b/docs/MFL/LAP/Underwriting/DOA.md
new file mode 100644
index 00000000..32f4a422
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/DOA.md
@@ -0,0 +1,80 @@
+
+DOA: Delegation of Authority
+
+The loan approval authority is determined based on two key criteria: the loan amount and the associated risk grade (refer to the DOA logic at the bottom of this sheet)
+
+
+Risk Grade
+
+ - This is derived from the BRE 0 during the QDE stage
+ - The risk grade is identified using the output key ‘final_risk_score’ in Pre Eligibility Check v0.0.8
+ - ‘final_risk_score’ is obtained for the primary applicant and all co-applicants; the highest risk score among them is considered (as Risk grade) for the DOA decision-making
+
+
+Loan Amount
+
+ - This amount is defined by the BCM within the Loan Offer module
+
+
+
+ - The approval authority (role level) is established whenever the loan offer is created or updated, as per the DOA approval logic
+ - This authority role is visible on the ‘Manual Credit Review’ tab
+ - The BCM initiates the DOA process by either approving the loan or escalating it to the next higher authority, the CCM
+ - Once the BCM escalates the case, the entire application becomes locked for edits by the BCM and all other users
+ - During this phase, only higher-level credit authorities can add sanction conditions or manage deviations (raise, approve, or reject)
+ - Each authority can escalate the case only to the immediate next higher authority in the hierarchy until it reaches the final approval authority
+ - For example, CCM can escalate only to SCM
+ - Authorities at or below the approval authority have the option to reject the case, with mandatory input of a rejection reason and sub-reason
+ - The ‘Current State’ displayed on the Manual Credit Review tab indicates the loan sanction status, such as Approved, Rejected, or displays the current DOA assignee (role level) handling the approval
+ - Any authority may also return the case to a lower authority for further review (MFL suggests this should be exclusively to BCM, pending implementation)
+ - Once returned, BCM can reinitiate the DOA flow, passing the case upward authority by authority as before
+ - Only the approval authority and higher may approve the case, provided the user has sufficient individual sanction limits (following modifications suggested by MFL are pending - approval authority shouldn’t be able to send the case further up)
+ - Each credit manager, regardless of level, holds an individual sanction limit which may be equal to or lower than the role-level sanction threshold
+ - For instance, a BCM’s role-level sanction limit for risk grades 1, 2, and 3 might be ₹10 lakhs, but a BCM in Vellore could have an individual limit of ₹8 lakhs
+ - When an approval authority attempts to approve, the system verifies the individual sanction limit
+ - Approval is permitted only if the individual limit is greater than or equal to the loan amount
+ - If the individual sanction limit is insufficient, the case is escalated to the next higher authority
+ - The system repeats the limit check at every level until reaching an authority with an adequate limit
+ - Upon approval, the case automatically advances to the next stage “In-principal sanctioned”
+ - Whenever a case is assigned to a higher authority for DOA by BCM, it appears in that authority’s pool under the task name “Manual Credit Review”
+ - An authority must self-assign the task to perform any actions on the case, such as approval or rejection
+ - DOA flow cannot initiate unless all deviations are approved
+ - If any deviation is rejected, the system prevents initiation of the DOA flow
+ - If any new deviations are raised by higher credit authorities while DOA is in progress, DOA actioning (loan approval/rejection) isn't allowed until all pending deviations approved
+
+
+Credit Approval Hierarchy
+
+Branch mortgage hierarchy:
+BCM → ACM → RCM → SCM → ZCM → NCM → CBO
+
+PC mortgage hierarchy:
+BCM → CCM → SCM → ZCM → NCM → CBO
+
+
+Currently, RCM level is omitted due to absence of RCM users but may be included based on future business needs
+
+
+DOA logic
+
+
+
+
+ | Credit Family |
+ Loan Amt$ |
+ Risk Grade |
+ FOIR |
+ LTV |
+
+
+
+ | BCM# | 10,00,000 | 1,2,3 | 50% | 60% |
+ | BCM# | 5,00,000 | 4,5 | 50% | 60% |
+ | CCM | 15,00,000 | 1,2,3 | 50% | 60% |
+ | CCM | 10,00,000 | 4,5,6 | 50% | 60% |
+ | SCM | 25,00,000 | 1,2,3 | 50% | 60% |
+ | SCM | 15,00,000 | 4,5,6 | 50% | 60% |
+ | ZCM | 30,00,000 | 1,2,3 | 50% | 60% |
+ | ZCM | 20,00,000 | 4,5,6 | 50% | 60% |
+ | NCM | 5,00,00,000 | 1,2,3,4,5,6,7,8 | 50% | 60% |
+ | CBO | 5,00,00,000 | 1,2,3,4,5,6,7,8 | 50%Legal Verification Workflow
+
+
+The BCM views the un-initiated Legal verification task in the
+Verifications tab and initiates it from there.
+
+
+Workflow Sequence
+
+BCM → Legal Vendor (out of scope) → State-level Legal Manager
+
+
+Task Initiation and Assignment
+
+ -
+ The BCM obtains the legal report from an empanelled legal vendor or lawyer
+ outside the system.
+
+ -
+ Uploading the legal report is mandatory while assigning
+ the task.
+
+ -
+ The BCM assigns the task to a state-level legal manager by selecting the
+ relevant manager from a dropdown of mapped state managers.
+
+ -
+ Once assigned, the task appears in the legal manager’s queue.
+
+
+
+Legal Manager Review
+
+ - Review the uploaded legal report and documents
+ - Optionally upload additional documents
+ - Add remarks
+
+
+Decision Options
+
+ - Recommended
+ - Not recommended
+ -
+ Hold – sends the task back to the same BCM for
+ clarifications or additional documents, after which the BCM can re-assign
+ it
+
+
+
+Decision Rules and Visibility
+
+ -
+ Once recorded, the decision cannot be edited or reversed.
+
+ -
+ The legal verification task cannot be reopened.
+
+ -
+ The decision does not block the overall underwriting flow.
+
+ -
+ All uploaded documents remain viewable from:
+
+ - The legal verification task
+ -
+ The “Technical verification” category under the
+ “All documents” tab
+
+
+
+ -
+ Task movement and remarks are visible in the
+ “Timeline” sub-tab.
+
+
diff --git a/docs/MFL/LAP/Underwriting/Loanoffer.md b/docs/MFL/LAP/Underwriting/Loanoffer.md
new file mode 100644
index 00000000..f7a6bb86
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/Loanoffer.md
@@ -0,0 +1,204 @@
+
+
+
+Loan Offer Configuration – MFL LAP
+
+
+
+ Loan Offer Configuration – MFL LAP
+
+
+ BCM manually sets the loan offer for MFL LAP during the “Under review” stage
+ in the “Loan offer” tab.
+
+
+ While configuring the loan offer, the BCM inputs the following parameters:
+
+ Product Configuration
+
+
+ -
+ Super product: Default is “LAP” and is auto-populated.
+ “Housing loan” is not supported currently.
+
+ -
+ Product: One of the following can be selected:
+
+ - General LAP
+ - Micro LAP
+ - SBL
+
+
+ -
+ Sub-product: One of the following can be selected:
+
+ - Top-up with closure
+ - New application
+ - Balance transfer without top-up
+ - Balance transfer top-up
+ - Resale
+ - Under construction
+
+
+
+ -
+ Scheme: Based on the selected product and the state where the loan was sourced,
+ the BCM is shown eligible schemes as defined in the
+ “Product-level scheme collateral policy master” (attached with mail).
+ RO login details are used to derive the state.
+
+ -
+ Property type: Based on product, state, and scheme, the system shows the
+ permitted property types as per the
+ “Product-level scheme collateral policy master”.
+
+ -
+ Loan purpose: One of the following can be selected
+ (This is the UAT master, Finbox is discussing the prod master with MFL):
+
+ - Business expansion
+ - Education purpose
+ - Home renovation/improvement
+ - New business
+
+
+
+
+ Financial Parameters
+
+
+ -
+ Loan amount (INR): The amount the BCM intends to sanction.
+ The “Product-level scheme collateral policy master” defines minimum and maximum
+ permissible loan amounts by product, scheme, etc.
+
+ -
+ If the entered amount is outside this range, the system allows submission but
+ displays a warning that “loan amount norms are not met”.
+
+ -
+ The BCM can subsequently raise a deviation in the deviations module
+ (auto-deviation is not yet implemented).
+
+
+
+ -
+ ROI (%): The rate of interest the BCM wants to offer.
+ The “Product-level scheme collateral policy master” defines threshold minimum and
+ maximum ROI based on product/scheme/property type/state etc (Refer master).
+
+ -
+ If the entered ROI is outside this range, the system allows submission but
+ displays a warning that “loan amount norms are not met”.
+
+ -
+ The BCM can later capture this as a deviation.
+
+
+
+ -
+ Tenure (months): The tenure offered.
+ The master specifies a maximum permissible tenure based on product/scheme/property
+ type/state etc (Refer master).
+
+ -
+ If the entered tenure exceeds this, the system still allows submission but
+ warns that “tenure norms are not met”.
+
+ -
+ The BCM can raise a corresponding deviation later.
+
+
+
+
+ -
+ Tranche type:
+
+ - Single tranche
+ - Multi tranche
+
+
+
+ -
+ FOIR (%): The BCM manually calculates and enters the FOIR.
+ The master defines a maximum permissible FOIR based on product/scheme/property
+ type/state etc.
+
+ -
+ If the entered FOIR exceeds this limit, the system permits submission but
+ shows a warning that “FOIR norms are not met”.
+
+ -
+ The BCM can later record this as a deviation.
+
+
+
+
+ -
+ LTV (%): Auto-calculated from the loan amount and total property value.
+ The master defines a maximum permissible LTV based on product/scheme/property
+ type/state etc.
+
+ -
+ If the calculated LTV exceeds this internal threshold, the system shows a
+ warning that “LTV norms are not met” but still allows submission.
+
+ -
+ The BCM can subsequently raise a deviation.
+
+ -
+ There is a hard stop of 20% ≤ LTV ≤ 75%.
+ If LTV falls outside this range, the system blocks submission of the loan offer.
+
+ -
+ LTV is recalculated every time the loan offer is submitted or edited, but it
+ does not auto-refresh when only “Total property value” is edited.
+
+ -
+ “Total property value” and other collateral details must be completed before
+ the loan offer can be set.
+
+
+
+ -
+ Processing fee (%): The processing fee the BCM wants to offer.
+ The permissible range is 2%–3%.
+ Values outside this range are not allowed and the system blocks submission.
+
+
+
+ Derived Fields (Post Submission)
+
+
+ After the BCM submits the loan offer, the system derives and displays additional
+ fields on the Loan offer tab:
+
+
+
+
+
+ The BCM can edit the loan offer as long as the application remains in the
+ “Under review” stage.
+
+
+
+
diff --git a/docs/MFL/LAP/Underwriting/OtherVerification.md b/docs/MFL/LAP/Underwriting/OtherVerification.md
new file mode 100644
index 00000000..c8c8bd75
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/OtherVerification.md
@@ -0,0 +1,32 @@
+Other Verifications
+
+
+In the “Under review” stage, the BCM can manually initiate
+parallel verifications from
+Verifications → “Other verifications” sub-tab.
+
+
+Mandatory Parallel Verifications
+
+ - Technical verification
+ - Legal verification
+ - RCU verification
+
+
+Initiation and Completion Rules
+
+ -
+ Initiating all three verifications in the
+ “Under review” stage is mandatory.
+
+ -
+ Completion and decisioning of these verifications is
+ not required during the
+ “Under review” stage.
+
+ -
+ All three verifications must be completed before final sanction,
+ specifically at the
+ “In-principle sanctioned” stage.
+
+
diff --git a/docs/MFL/LAP/Underwriting/PrimaryVerification.md b/docs/MFL/LAP/Underwriting/PrimaryVerification.md
new file mode 100644
index 00000000..ea05ee45
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/PrimaryVerification.md
@@ -0,0 +1,35 @@
+Primary Verifications
+
+
+In the “Verifications” tab, under the
+“Primary verifications” sub-tab, the BCM completes all primary
+verification activities.
+
+
+Mandatory Primary Verification Forms
+All of the following forms are currently mandatory:
+
+ - Residence verification
+ - Property verification
+ - Family tree
+ - Personal discussion – for the applicant and all co-applicants
+ - Tele-verification – for the applicant and all co-applicants
+ - Risk gradation
+
+
+Form Submission Rules
+
+ -
+ A form cannot be submitted unless all mandatory fields are filled.
+ Any field-level validation failures are displayed as front-end errors.
+
+ -
+ After completing each form, the BCM must close the corresponding task
+ by clicking the tick button against that form.
+ Until this action is completed, the verification is not treated as complete.
+
+ -
+ A form can be edited only until its corresponding task is marked complete.
+ Once the task is completed, the form becomes non-editable.
+
+
diff --git a/docs/MFL/LAP/Underwriting/RCUStage1.md b/docs/MFL/LAP/Underwriting/RCUStage1.md
new file mode 100644
index 00000000..f9f88045
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/RCUStage1.md
@@ -0,0 +1,141 @@
+
+RCU Stage 1 Verification
+
+
+The BCM identifies the un-initiated RCU verification task in the
+Verifications tab and initiates it.
+
+
+Workflow Sequence
+
+BCM → RCU Vendor → State-level RCU Manager
+
+
+Task Assignment
+
+ -
+ The BCM assigns the RCU task to an RCU vendor selected from the list of vendors
+ mapped to the relevant state.
+
+ -
+ Once assigned, the task appears in the RCU vendor’s queue.
+
+
+
+RCU Vendor Activities
+
+ - Screen all customer-related documents uploaded in the system
+ -
+ Provide a final RCU decision, optionally uploading a supporting report or
+ document
+
+
+
+Document Screening Statuses
+
+ - Screened – cleared
+ - Sampled – requires further investigation
+ - Hold – cannot be screened for some reason
+ - Under review – default state, not yet screened
+
+
+Documents Subject to Screening
+Screening is performed only on manually uploaded customer documents:
+
+ - KYC Uploaded
+ - Financial Docs
+ - Address
+ - Collateral
+ - Additional Doc
+ - Business
+
+
+Documents Excluded from Screening
+
+ -
+ KYC documents fetched from third-party APIs (e.g. Digilocker)
+
+ -
+ System-generated or internal categories such as
+ “Verifications”
+
+
+
+Screening Validation Rules
+
+ -
+ If any document remains in Hold or
+ Under review, the system blocks:
+
+ - Final RCU decision submission
+ - Progression of the RCU workflow
+
+
+
+
+Final RCU Decisions (Vendor)
+
+ - Positive
+ - Negative
+ - Could not verify
+ - Refer to Credit
+ - R-Doc
+ - R-Profile
+ -
+ Hold – sends the task back to the BCM for resolution, after
+ which the BCM can reassign it to the RCU vendor
+
+
+
+Escalation to State-level RCU Manager
+The task is escalated automatically if:
+
+ - Any document is marked Sampled
+ -
+ The vendor’s final decision is:
+
+ Negative, Could not verify, Refer to Credit, R-Doc, or R-Profile
+
+
+
+
+
+If neither condition is met, the RCU flow ends with the vendor’s decision.
+
+
+State-level RCU Manager Capabilities
+
+ - Screen documents
+ - Modify document screening statuses
+ - Override the vendor’s final decision
+ -
+ The manager cannot use the
+ “Hold” status while screening documents
+
+
+
+Final Decision by RCU Manager
+
+ -
+ The RCU manager can select Hold as the final decision to send
+ the task back to the BCM for clarification
+
+ -
+ The BCM can reassign the task to the RCU manager after addressing the issues
+
+ -
+ Once the RCU manager records a final decision, the RCU workflow
+ ends
+
+
+
+Post-RCU Actions
+
+ -
+ Based on the final RCU outcome, the BCM can raise RCU-related deviations in the
+ Deviations module
+
+ -
+ In future phases, these deviations will be auto-triggered by the system
+
+
diff --git a/docs/MFL/LAP/Underwriting/Readme.md b/docs/MFL/LAP/Underwriting/Readme.md
new file mode 100644
index 00000000..9c4f405c
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/Readme.md
@@ -0,0 +1,71 @@
+
+BCM – Under Review Stage
+
+
+Once BPO Stage 1 forwards a case, the application moves to the BCM pool in the
+“Under review” stage. It remains there until a BCM self-assigns it,
+after which it appears in that BCM’s queue for processing.
+
+
+BCM Activities in “Under review” Stage
+
+ - Completes all primary verifications (FI/PD)
+ - Initiates parallel verifications (Legal, Technical, RCU)
+ - Uploads the CAM report
+ - Updates collateral details
+ - Sets the loan offer
+ - Raises deviations
+ - Raises sanction conditions
+ - Completes risk profiling
+ - Initiates the DOA flow
+
+
+Key Sequence and Validation Rules
+
+ - All primary verifications must be completed before CAM upload
+ - CAM must be uploaded before setting the loan offer
+ - All mandatory collateral details must be captured before setting the loan offer
+ - Property address line 2 and landmark are optional fields
+ - Built-up area is optional if property type is Flat
+ - Super built-up area is optional if property type is Independent
+ - Carpet area must be less than built-up area
+ - Built-up area must be less than super built-up area
+ - The loan offer must be set before raising deviations, as deviations depend on the selected loan product (e.g. General LAP, Micro LAP, SBL)
+ - The loan offer must be set before initiating both DOA flow and risk profiling
+ - The BCM checklist for this stage must be completed before initiating DOA flow
+ - All deviations must be resolved and in “Approved” status before DOA flow can be initiated
+ - At least one bank account for either the applicant or co-applicant must be added before initiating DOA, if not already present (to be implemented)
+
+
+Additional Rules and Permissions
+
+ -
+ In parallel with the above activities, the BCM can modify information entered by RO/CO
+ in earlier stages, except for:
+
+ - Sourcing details
+ - Requested loan details
+ - IMD details
+
+ These fields are locked for editing.
+
+ - The BCM can upload additional documents to the application if required
+ -
+ The BCM cannot add a co-applicant in the “Under review” stage.
+ To add a co-applicant, the case must be sent back to an earlier stage.
+
+ -
+ The BCM can generate unsigned documents such as:
+
+ - Sanction Letter
+ - LAF
+ - KFS
+ - Loan Agreement
+ - SOC
+ - GTC + MITC
+
+ during the “Under review” stage.
+
+ (Separate note to be shared on document generation)
+
+
diff --git a/docs/MFL/LAP/Underwriting/Riskprofiling.md b/docs/MFL/LAP/Underwriting/Riskprofiling.md
new file mode 100644
index 00000000..c8cf5659
--- /dev/null
+++ b/docs/MFL/LAP/Underwriting/Riskprofiling.md
@@ -0,0 +1,89 @@
+
+
+
+
+ Risk Profiling – LAP
+
+
+ BCM can perform risk profiling either in the “Under review” stage or the
+ “In-principle sanctioned” stage; it becomes mandatory at the
+ “In-principle sanctioned” stage.
+
+
+
+ The risk profiling module takes a set of input parameters and, based on a predefined scoring
+ logic, returns an overall risk score and a corresponding risk category.
+
+
+
+ Each input is treated as a question with a response that contributes a specific score, and the
+ sum of these individual scores yields the final risk score (a value between 0–100)
+ and risk category (Low, Medium, or High).
+ (Logic attached with this mail)
+
+
+ Risk Profiling Form
+
+
+ BCM fills a form on the “Manual Credit Review” tab to calculate the risk profile.
+
+
+ The inputs required to calculate the risk score are:
+
+
+ -
+ Nature of property: Selected by the BCM from a master list
+
+ -
+ FOIR: Auto-fetched by the system from the loan offer details
+
+ -
+ LTV: Auto-fetched by the system from the loan offer details
+
+ -
+ Vintage: Entered manually by the BCM (free-text field)
+
+ -
+ Occupation type: Selected as either “Salaried” or “Self-employed” by the BCM
+
+ -
+ Occupation: Selected by the BCM from a master list
+
+ -
+ Guarantor in deal: Selected as “Yes” or “No” by the BCM
+
+
+
+
+ The loan offer must be set before running risk profiling, since FOIR and
+ LTV are required as inputs for the calculation.
+
+
+
+ The system does not impose any hard validation or blocking condition based on
+ the resulting risk score or risk category; the outcome is for assessment purposes only.
+
+
+
+ The BCM can edit the risk profiling form and recalculate the risk score until the case moves to
+ the “Loan sanctioned” stage.
+
+
+ Risk Gradation
+
+
+ Risk gradation is a separate verification, for which BCM fills a form mandatorily in the
+ “Under review” stage under Primary verifications on the
+ “Verifications” tab.
+
+
+ Reference Document
+
+
+
+ LAP Credit Risk Profiling (3) 1.xlsx
+
+
+
+
+ |