Understanding Document (UD)

Company Confidential

For

Client, Mumbai
India

By
Registered Address: Corporate Office and Mailing Address:

Nucleus Software Exports Ltd. Nucleus Software Exports Limited

33-35 Thyagraj Nagar, New Delhi - 110003, A-39, Sector - 62, Noida
India Uttar Pradesh - 201301 (INDIA)
Tel. 91 - 11 - 2462 7552 Phone : +91-120-2404050
Fax 91 - 11 - 2462 0872 Fax : +91-120-2403976

Template Restricted circulation only Page 1 of 21

Table of Content for Understanding Document

1 Introduction......................................................................................................................................................... 3
1.1 Scope of Work\Objective of the Document..................................................................................................... 3
1.2 Definitions & Acronyms ................................................................................................................................... 3
1.3 References .......................................................................................................................................................... 3
2 Functional Description ....................................................................................................................................... 3
2.1 Enhancement Description .................................................................................................................................. 3
2.1.1 Existing Process/Module Description .................................................................................................... 3
2.1.2 Processing/Proposed solution ................................................................................................................. 3
2.1.2.1 Process Flow for builder funding ........................................................................................................... 3
2.1.2.1.1 Process flow for loan booking for the builder....................................................................................... 4
2.1.2.1.1.1 Change in Master ............................................................................................................... 4
2.1.2.1.1.2 Change in transaction ........................................................................................................ 4
2.1.2.1.1.2.1 Rating Score and rating model ...................................................................................... 4
2.1.2.1.1.3 Property/Project detail capturing..................................................................................... 7
2.1.2.1.1.3.1 Project details in CMS .................................................................................................. 11
2.1.2.1.1.3.2 Project Master ............................................................................................................... 12
2.1.2.1.1.4 Underwriting .................................................................................................................... 14
2.1.2.1.1.5 Tranche Initiation: ........................................................................................................... 14
2.1.2.1.1.6 Disbursal maker-checker: ............................................................................................... 14
2.1.2.1.1.7 Technical/Legal Initiation process: ................................................................................ 16
2.1.2.2 Process Flow for retail loans ................................................................................................................ 16
2.1.2.2.1 Change in Masters for Retail Adjustments ......................................................................................... 16
2.1.2.2.1.1 Product Master: ............................................................................................................... 17
2.1.2.2.1.2 Builder Master: ................................................................................................................ 17
2.1.2.2.2 Change in Transaction for Retail Adjustments .................................................................................. 17
2.1.2.2.2.1 Change in property detail screen.................................................................................... 17
2.1.2.2.2.2 Underwriting .................................................................................................................... 18
2.1.2.2.2.3 PDOC ................................................................................................................................ 18
2.1.2.2.2.4 Disbursal ........................................................................................................................... 19
2.1.2.3 Query Screen Formats\Input Forms Formats\User Interface \Screenshots .................................... 20
2.1.2.3.1 Formulas ................................................................................................................................................ 20
2.1.2.3.2 Sorting Criteria ..................................................................................................................................... 20
2.1.2.3.3 Test Data required ................................................................................................................................ 20
2.1.2.3.4 Data from External Interface ............................................................................................................... 20
2.1.2.4 Impact on other FinnOne Module used ,if applicable ....................................................................... 20
3 Non Functional Requirements ......................................................................................................................... 20
3.1 Outstanding points .......................................................................................................................................... 20
3.2 Portability Requirements ............................................................................................................................... 20
3.3 Reliability Requirements ................................................................................................................................ 20
3.4 Availability Requirements .............................................................................................................................. 20
3.5 Maintainability Requirements ....................................................................................................................... 20
3.6 Performance Requirements ........................................................................................................................... 20
3.7 Security Requirements ................................................................................................................................... 20
3.8 Usability Requirements .................................................................................................................................. 20
4 Issues & Concerns / RISKS (if any) ................................................................................................................ 21
5 Assumptions ...................................................................................................................................................... 21
6 Transaction Volumes (if any/shared by client) .............................................................................................. 21
7 Appendix ............................................................................................................................................................ 21
7.1 Requirement matrix.\Mail reference (Optional) ......................................................................................... 21
7.2 Any other project related document (like BRD from customer, report formats, case studies etc) ......... 21

Template Restricted circulation only Page 2 of 21

1 Introduction

1.1 Scope of Work\Objective of the Document

The objective of this document is to cover requirement understanding and the proposed solution for
production enhancements elicited by CLIENT. The proposed solution will cater the business needs and
provide the required functionality and required reports in desired format.

This document will facilitate the business user to understand the business requirement Vs proposed solution
in FinnOne system. This document will also serve as a tool for the requirement gathering and proposed
solution. It will be used for tracking delivered functionalities as per scope of work mentioned in this
document.

This document will freeze the top-level design and would lead to detailed design and development phase of
the project for construction purchase business for CLIENT. The overall scope of work is mentioned in
detailed; any thing, which is not mentioned in this document, is considered outside the scope of this
enhancement/project.

1.2 Definitions & Acronyms

Acronyms Description
CLIENT Client
Nucleus/NSEL Nucleus Software Export Ltd.
Issue Id Request logged in Request system of Nucleus for Enhancement type
issue
LMS FinnOne - Loan Management System
LOV List of values
CMS Collateral management system
DF Dealer funding

1.3 References
None

2 Functional Description
2.1 Enhancement Description

CLIENT is introducing construction purchase as one of the products in the existing business.

2.1.1 Existing Process/Module Description

The flow so required for construction purchase business exists partially in the existing system, but some
modifications as explained below would be required for the meeting the complete requirement.

2.1.2 Processing/Proposed solution

2.1.2.1 Process Flow for builder funding

The process flow for the loan to the builder for under construction property will be as per the below figure.

Template Restricted circulation only Page 3 of 21

2.1.2.1.1 Process flow for loan booking for the builder

The loans for construction purchase will be handled through the existing DF module. The provision for builder
funding will be available in the menu option for dealer funding only. The loan for builder funding will be funded to
only corporate entities.The work flow for Deal and tranche will remain the same as dealer funding. Following
changes will be done in the system for construction purchase.

The below mentioned changes will be done in the DF module for construction purchase only. However if the
customer comes for funding of land then the same will be handled through retail loans. Construction purchase
option should be used only when the builder has a documented plan for constructing on the project.

2.1.2.1.1.1 Change in Master

A new field builder funding flag will be added in the product master. This field will be a drop down with two
values as ‘Yes’ and ‘No’. Only those products will be available for loan booking cor construction which have
builder funding flag as Yes.

2.1.2.1.1.2 Change in transaction

2.1.2.1.1.2.1 Rating Score and rating model

Currently system allows executing only one rating model for one application. As per the requirement CLIENT
executes two rating models for each application and get the combined rating basis the score and rating of the two
individual models. Thus the risk rating process will be modified to execute multiple ratings for an application as
shown below.

Template Restricted circulation only Page 4 of 21

The two rating models that will be configured for construction purchase are
1. Builder Rating Model
2. Project Rating Model

Builder Rating Model

Builder Rating Model will have following fields.

Template Restricted circulation only Page 5 of 21

Builder rating –score grid will be as shown below.

Builder Score Builder Rating

Greater Than 4.5 A
4.0-4.5 B
3.0-4.0 C
2.0-3.0 D
1.5-2.0 E
Less Than 1.5 F

Project rating model

Project rating model will have following fields

Project rating –score grid will be as shown below.

Project
Project Score Rating
Greater Than 4.5 A
4.0-4.5 B
3.0-4.0 C
2.0-3.0 D
1.5-2.0 E

Template Restricted circulation only Page 6 of 21

 Less Than 1.5 F

Note: The values for each drop down will have values as per the sheet attached in the appendix.

Combined rating

A new tab will be provided in risk rating activity which will be enabled only when both the builder and project
ratings have been executed for an application. Combined rating of both builder and project rating will be displayed
under the combined rating tab as shown below.

The combined rating grid will be

Project Rating
A B C D E F
A      
Buider Rating

B      
C      
D      
E      
F      

2.1.2.1.1.3 Property/Project detail capturing

A new tab property detail screen will be added in deal initiation stage as shown below to capture the project details.
This screen will be used to capture the basic details like builder name, project, building, wing and project address.
The property detail will be similar to the property detail screen in retail loans. The property details added on
property screen will move to CMS module as primary collateral as per the existing functionality. The properties
added in the CMS will be treated as secondary collateral while the project entered in property detail screen will be
treated as primary collateral.

The same screen will be provided in PDOC stage in tranche for construction purchase so as to enable the user to
enter the project details before disbursal.

Template Restricted circulation only Page 7 of 21

The property detail screen for construction finance will be the same as the screen being used in retail loans for
capturing property details.

1. Following fields will be made mandatory in addition to the existing mandatory fields on property detail
screen for construction purchase product.
a. Builder Group
b. Builder Name
Template Restricted circulation only Page 8 of 21
 c. Project Name

2. Following changes will be made on property detail screen

a. The address block will be auto populated from the address captured in the project master.
Project master has the provision to capture address for each project. User can enter multiple
addresses against the project. A new validation will be incorporated in project master that one
mailing address is mandatory to capture for a project. The mailing address for the project will be
auto populated on the property detail screen o selecting a particular project.

Fig 1. Project Address Master

b. A new field no of units will be added on property detail screen to capture the no of flats/shops that
are targeted to be constructed. This field will be mandatory to be captured on property detail
screen.

c. Capturing Escrow details: escrow details will be added on property details screen in the builder
detail section as shown below. Following fields will be added to capture all the escrow account
details of the builder.

 City >> this field will be an LOV. It will be populated from PDC city master. This field
will be used to capture the city of the bank
 Bank >> this field will be an LOV .Based on city , banks will be populated from PDC
bank master. This field will be used to capture the bank name.
 Bank Branch >>this field will be an LOV .Based on bank , bank branches will be
populated from PDC bank branch master. This field will be used to capture the branch of
the account holding bank.
 MICR >> Based on the combination of city,bank,bank branch MICR code will get auto
populated. User will also have an option to either enter the MICR code and based on the
values added in this field above three fields will get auto populated.
 Escrow Account Number >> It will be free text field to capture the escrow account
number.

Template Restricted circulation only Page 9 of 21

Clicking on funds available button will open the below screen for capturing the sources of availability of the funds.

Clicking on construction purchase button will open the below screen for capturing the complete information
regarding the purchase and construction of the property for which the loan has been applied

Template Restricted circulation only Page 10 of 21

Clicking on Tranche details button will open the below screen for capturing the project cost.

2.1.2.1.1.3.1 Project details in CMS

All the project details will be added in CMS module. A new collateral type “project details” will be created in the
system. Thus the flat/shop information will be captured as secondary collateral in CMS under collateral type as
project details. The property detail screen in CMS will be as per the existing screen currently being used by
CLIENT.

Template Restricted circulation only Page 11 of 21

It will be optional to enter the property details in CMS at deal level. However it will be mandatory to capture the
primary collateral/project details on property details screen before the underwriter sanctions the loan at deal level.

2.1.2.1.1.3.2 Project Master

A new field Builder funded flag will be added in the project master so as to identify the projects which are
applicable for builder funding. This field will be a drop down with two values as ‘Yes’ and ‘No’. Only those
projects will be applicable for builder funding if the value in this field is chosen as Yes.

Following new fields will be added on project master screen to capture the project details.
1. Promoter scheme >> this will be a free text field of length 35

Template Restricted circulation only Page 12 of 21

 2. Joint venture share >> this will be a user enterable numeric field
3. Land area >> this will be a user enterable numeric field
4. Type of land >>>> this will be a free text field of length 35

Project Master

Building and wing details will be captured in the existing building and wing master respectively as shown below.

Building Master

Template Restricted circulation only Page 13 of 21

 Wing Master

2.1.2.1.1.4 Underwriting

The underwriting screen will remain the same.

Escrow account check: If the escrow account number is not updated in the property detail screen then system will
raise an automated deviation. Thus sanctioning of the loan will be possible only when either the escrow details are
updated on the property detail screen or the deviation is approved by the sanctioning authority to move ahead
without the escrow account details.

Project details: A new check will be incorporated on press of save and proceed button which will check that
project information have been entered in the property detail screen .

CAM: Currently CAM report is generated on the basis of the product category. Now since builder funding and
dealer funding will come under the same product category as ‘DFUND’ so the report generation logic will be
changed to include the product in order to separate the CAM report for dealer and builder funding. New Cam report
will be developed for construction purchase as per the format shared by CLIENT.<< CAM format attached in the
appendix>>.

2.1.2.1.1.5 Tranche Initiation:

All the deals will be single tranche only.

2.1.2.1.1.6 Disbursal maker-checker:

1. The facility to disburse multiple disbursements within a tranche will be provided in the system. DISB-DTL
stage will be added in the workflow which will allow disbursing single tranche in multiple disbursals for
builder funding loans.

For e.g. If Deal amount is Rs.5000000 then tranche amount will also be Rs.5000000. Now the facility
to disburse this Rs.5000000 in multiple disbursals will be provided. Thus disb-dtl will be added
before disbursing the amount in the tranche workflow. Disb-dtl screen will work exactly in the same
order as currently working in retail loans.

2. A validation will be incorporated on press of disbursal initiation button on disb-dtl screen which will
validate at the time of first disbursal that the number of secondary collaterals with collateral type as project
details in CMS for the particular deal is equal to the no of units entered in the property detail screen. If
Template Restricted circulation only Page 14 of 21
 there is a mismatch in the two numbers being compared, system will not allow disbursing the loan amount
for the tranche. This validation will be incorporated so as to ensure that the project/building/wing/flat no
details are added before the disbursal for construction purchase loan is initiated.

3. A validation will be incorporated on press of disbursal initiation button on disb-dtl screen which will
validate that if disbursal amount for a particular disbursal exceeds the percentage of technical verification
done for the application system will not allow to disburse the loan until the approval for disbursal has been
taken from the concerned authority. FinnOne would provide an Override button on DISBDTL screen as
shown below. An override with code O_TIV will be maintained in the system. User will enter the approval
against the mentioned override in the override screen in case of any deviation. A validation will be
developed on Disbursal Initiation button, which will check the presence of the override code O_TIV if the
amount of disbursal exceeds the percentage completion of the property.

Clicking on override button will open the below screen to capture the override.

Description field will contain the description of the waiver approval user has taken. Role field will capture the
role/designation of the person who has approved the waiver and sanctioned by will capture the name of the user of
the person who has authorized the waiver. This LOV will get populated on the basis of the role chosen.

Since sanctioning authorities for overrides may not be actual users in the system. So a separate sanctioning
authority master would be provided to maintain sanctioning authority names and designation as shown below.

Template Restricted circulation only Page 15 of 21

2.1.2.1.1.7 Technical/Legal Initiation process:

The technical and legal verification which is executed in retail loans will be plugged-in in corporate loans also. This
activity will be made independent of work flow so that CLIENT can perform technical/legal verification at any
point of time. The format for legal and technical verification will remain same as per the current verification screen
in retail loans.

2.1.2.2 Process Flow for retail loans

The process flow for the loan to the customer who takes the loan from CLIENT for a property which has been
already funded to a builder under construction purchase will be as per the below figure. It should be noted that this
process will be followed under the retail loans.

2.1.2.2.1 Change in Masters for Retail Adjustments

Template Restricted circulation only Page 16 of 21

2.1.2.2.1.1 Product Master:

A new field retail adjustment applicable will be added in the product master. This field will have two values as yes
and No. It will be mandatory to select this field while maintaining any new product. If the value in this field is
chosen as Yes only then retail adjustment will be possible at the transaction level.

2.1.2.2.1.2 Builder Master:

A new tab deal details will be added in the builder master to capture the deal associated with the builder. It should
be noted that if the mapping of the deal and the builder is not done in masters then retail adjustment will not be
possible for a retail application. The builder-deal mapping tab will capture the below information.

The drop down for deal Id will display all the deals which have product as Construction purchase associated with it.

2.1.2.2.2 Change in Transaction for Retail Adjustments

2.1.2.2.2.1 Change in property detail screen

Following changes will be done on the existing property detail screen to copy the property details

A new field project details will be added on property details screen.. This field will be an LOV which will display
the project information so as to enable the user to select the property to be funded from the already funded deal
under construction purchase to the builder. The value in this filed will get populated if
1. The builder selected in property details screen is mapped to one of the deals ad described in section
2.1.2.2.1.2. Thus builder deal mapping should exist in the system.
2. The project selected in property details screen has builder funded flag as Yes. Refer section 2.1.2.1.1.3.2
for details.
3. The selected project has been funded under the product with builder funding flag as yes.
4. The deal so attached to the builder has records in CMS with collateral type as project details for secondary
collateral which have not yet been released to the builder.
If all the above conditions are met system will display the records in the below screen for user to select the
desired property.

Template Restricted circulation only Page 17 of 21

When user will check the desired record and press copy button, system will automatically copy the displayed
information on the property detail screen.

2.1.2.2.2.2 Underwriting

Retail adjustment is a process using which the amount that needs to be paid by the builder towards construction
purchase facility gets adjusted through the disbursements that needs to be done to the dealer by CLIENT for the
sanctioned loan. This adjustment will be done when the retail loans for the product is sanctioned in system and
disbursal is initiated, i.e., movement of loan from FinnOne CAS to LMS.

A new field retail adjustment will be provided on underwriting screen in CAS to specify whether retail adjustment
needs to be done or not as shown below. It should be noted that Retail adjustment applicable field will be enabled
and mandatory only if below conditions are true
1. Retail adjustment flag is ‘Yes’ at product level
2. The property details entered in property screen are copied using project details field.
3. The outstanding amount in builder’s loan a/c is greater than equal to the current loan amount to be
disbursed in retail loan.

While sanctioning a retail loan towards the builder to which the funding has already been made, underwriter will
specify whether the disbursement will happen to the builder/ retail adjustment will be done for that loan. To capture
this, provision will be provided at the underwriter screen in case of product category as ‘Home Loans’ to specify
whether retail adjustment needs to be done or not .

2.1.2.2.2.3 PDOC

If it is specified that retail adjustment needs to be done, then at PDOC stage it will become mandatory to specify the
retail adjustment for that loan in split disbursal screen. Change stage rule will be maintained for this purpose so that
if retail adjustment has not been specified, the system will not allow the loan to move further for disbursement.
However, if it is specified that retail adjustment need not to be done, normal cycle of disbursement will be followed
for the retail loan wherein the mode of payment of disbursement will be specified in the disbursal details stage of
FinnOne CAS.
If the user clicks on retail adjustment button, system will automatically populate the deal id on the basis of the
property selected in property details screen using the project details field. This field will be disabled on the retail
adjustment screen, if required in order to change the deal id , user needs to change the property details. User needs
to enter the amount in adjustment amount that needs to be adjusted in builder account.

Template Restricted circulation only Page 18 of 21

2.1.2.2.2.4 Disbursal

A validation will be added on disbursal initiation button of the disb dtl stage which will check that if retail
adjustment flag is chosen as Yes in UND screen then the property so selected in the loan should be released in CMS
from the builder’s account. If the property is not released in CMS, system will not allow to disburse the loan
amount.

If user chooses retail net off applicable as yes then at the time of disbursal of the retail loan the payment cheque
will not be issued to the customer. At the time of loan movement from CAS to LMS, system will internally add
one entry of bulk refund in builder’s loan and re-draw the new repayment schedule for him as per new reduced loan
amount..
For E.g

Description Amount(Rs)
Deal amount of builder 5000000
Amount disbursed to builder 2000000

Loan amount of the retail loan issued to the customer 1000000

When retail net off applicable is updated as Yes then following accounting entries will be passed by the system in
both builder’s and customer’s loan account.

Description Dr/Cr Amount Stage Remarks

Customer’s account( Retail Loan)
Loan Account Dr 1000000 A The entry at
Disbursement Ctrl A/c Cr 1000000 A the time of
Disbursement Ctrl A/c Dr 1000000 M loan booking
Retail adjustment Ctrl A/c Cr 1000000 M and payment
in
customer’s
retail loan
a/c.
Builder’s Account( Construction purchase Loan)
Retail adjustment Ctrl A/c Dr 1000000 J The entry for
Part PrePayment Control Account Cr 1000000 J part payment
Part PrePayment Control Account Dr 1000000 K will be done
Loan Account Cr 1000000 K in builders

Template Restricted circulation only Page 19 of 21

 Description Dr/Cr Amount Stage Remarks
loan a/c

2.1.2.3 Query Screen Formats\Input Forms Formats\User Interface \Screenshots

2.1.2.3.1 Formulas
None
2.1.2.3.2 Sorting Criteria
None
2.1.2.3.3 Test Data required
None
2.1.2.3.4 Data from External Interface
None
2.1.2.4 Impact on other FinnOne Module used ,if applicable
As explained in section 2.1.2

2.1.2.5 Interface Formats

3 Non Functional Requirements

3.1 Outstanding points

None
3.2 Portability Requirements
None

3.3 Reliability Requirements

None

3.4 Availability Requirements

None

3.5 Maintainability Requirements

None

3.6 Performance Requirements

None

3.7 Security Requirements

None

3.8 Usability Requirements

None

3.9 Operational Requirements

None

3.10 System Help Requirements

None

3.11 Scalability Requirements

None

Template Restricted circulation only Page 20 of 21

4 Issues & Concerns / RISKS (if any)
None
5 Assumptions
1. CIBIL for builders in case of builder funding will be done outside the system.
2.
6 Transaction Volumes (if any/shared by client)
None
7 Appendix
None
7.1 Requirement matrix.\Mail reference (Optional)
7.2 Any other project related document (like BRD from customer, report formats, case studies etc)

Description Document
Rating model values

Microsoft Office
Excel 97-2003 Worksheet

Document list and CAM

Template Restricted circulation only Page 21 of 21