Business Requirements Document (BRD)

Loan Origination System-Business Loan

November 2021

Version 1.00

1. Document Revision

1 Approvals

2 Introduction

2.1 Project Summary

Abc bank request for Loan Origination system –Business loan . It wants to move from legacy system to fully digital platform for Loan origination.

2.1.1 Background

The Banking Sector Has Had To Move Quickly To Digitalise Its Financial Services In Order To Serve More Clients Than Ever Before. IT Consumption Has Always Been Considerable In The Banking Industry, But A Giant Leap In Demand For Financial Services Has Accelerated IT Adoption Significantly And Has Been Remarkably Beneficial In Promoting Financial Inclusion.

Riding The Wave Of New Technologies, Banks Are Exploring Major Trends In Adopting More Efficient Risk Architectures. Their Management Clearly Understands That Having A Well-Designed Risk Architecture Will Allow Them To Offer A Greater Service Capacity, Provide Effective, Efficient, And Agile Risk Assessment, And Enhance Their Risk Analysis.

The Latest Trends Financial Institutions Are Embracing To Address Risk Architecture Concerns Generally Include Taking Competitive Advantage Of Computational Engine Based Credit Approval Involving ,Text Recognition, Artificial and ML Engines.

Adopting These Technologies Makes Digital Transformation Smoother And Shows Great Results In Fixing Many Related Risk Architecture Issues, Such As:

· High-Cost Computational And Storage Resources

· Poor Scalability

· Low And Slow Performance

· Slow Data Processing And Analytics

· Outdated Processes

· Client Complain, Leading To Reputational Loss

· Reporting And Mis Not Capturing Real Scenario At Given Point

2.1.1.1 Business Drivers

Post Epidemic The Possibility Of A Looming Credit Downturn Has Been A Hot Topic In Lending Industry , Though No One Predicted That A Pandemic Would Be The Cause. But The Reality Is That Lending Institutions Will Face Challenges While Borrowers Recover. Lenders Will Need To Be Especially Mindful To Avoid Costly Mistakes by Following Immediate Business Adjustments Outlined Below.

1. Adjust Automated Computational Decisioning

From Alternative Lenders To Traditional Banks, Automated Decisioning Has Become More Commonplace. In Any Situation, Making A Loan To A Borrower With A High Credit Score And Plenty Of Assets Without A Credit Analyst’s Review Makes Sense. However, In A Time Of Crisis A Business May Look Perfect On Paper And Yet Reality May Be Diffrent. The Scorecards And Algorithms Developed During Stable Economic Times Will Not Apply And Lenders Could End Up With A Non-Performing Loan On Their Books. Now Is The Time To Provide Case Based Adjusted Test Scorecards And Algorithms Quickly.

2. Increase Fraud Awareness

Economic Downturns And An Increase In Fraud Are Often Found Together. Faced With Tough And Emotional Decisions, Otherwise Honest Businesses May Be Tempted To Provide Falsified Documents To Secure A Loan Or Purport To Be Collecting On Outstanding Invoices They Know Won’t Be Repaid. Lenders Need To Be Extra Diligent In Verifying Information And Scrutinize Collateral Positions Employing New Machine Learning Engines With On Ground Verification Done Deligently

3. Adhere To Credit Policies

While Lenders Will Be Looking For Ways To Accommodate Their Current Borrowers, They Should Stick To Their Credit Policies For New Loans. If Lenders Deviate From Their Credit Policies To Make Loans To New Borrowers, They Risk Putting Themselves In A Position That Could Result In Downgraded Credits And An Increase In Non-Performing Assets Or Higher Credit Losses.

4. Competition

Competition Is Moving Towards Automated Process , Thereby Working On Thin Time Line Which New Age lending co. Think To Be A Norm.

Any Delay In Processing Will Lead To Loosing The Client To Competition.

2.2 Project Scope

Fig- Flowchart outlining the process to be expected

2.2.1 In Scope Functionality

· Create Name/Function/Role Records For Sub Widgets By Category Of

o User Interface

o Credit Maker

o FCU Widget

o Credit Checker

o Credit Control

o Risk Control

o Audit Control

o Operations

· Ability To Lock Widget By User When In Use

· Change In Widget Data Restricted By Role/Function

· Search By Name, Team, Date, Last Modified

· Synchronize Widgets Across Product/Operations Lines

· Provide Audit Trail To All Changes Made In Master Widget Repository

· Reporting On New, Modified, And Archived Widgets By Time Period And Team

2.2.2 Out Of Scope Functionality

· All Credit/eligibility/Fraud detection Algorithm to be given by ABC bank .

· Create Widgets For Bank Allied Product Lines

· Search By Approver, Or Rationale

· Archiving Of Widget Objects

· Synchronize Widgets Across Product/Operations Lines

· Computational Engine Parameter tweaking.

· Creation Of Pathways To Interact With Legacy Product

· Performance

· Reliability,

· Scalability,

· Maintainability

2.3 System Perspective

2.3.1 Assumptions

· No Major Overhaul In Governance Policy Of Bank /Fintech Industry Due To Rising NPA (Non Performing Asset) In This Economic Scenario.

· Inventory Of Existing Widgets Completed By Jan Q1.

· Testing Data Comprises Scrubbed Production Data As Of Q2 2022 .

2.3.2 Constraints

· Impending Changes To Privacy Regulations May Impact Data Dictionary Design.

· Timeline For Enterprise Platform Updates Will Impact Execution Of Testing Plan.

2.3.3 Regulatory And Risks

· Previously Approved Q1/Q2 2022, Development Projects May Limit Availability Of Development And QA Resources, Necessitating Outsourcing Or Additional Budget Requisitions To Meet The Anticipated Timeline.

2.3.4 Issues

· Ongoing Economic Conditions Can Result In New Guideline For Bank And Fintech Industry With Regards

* To Client/User Acquisitions ,User/Client Data Verification/Holding.

* In Event Of Above Scenario Project May Timeline May Get Affected With Cascading Effect On Resource Allocation And its effect on Other Planned Project line.

3 Business Process Overview

3.1 Current Business Process (As-Is)

Fig – Existing legacy system of ABC bank

3.2 Proposed Business Process (To-Be)

Fig- Flow of business requirement

ABC Bank seeks to implementing a secure, flexible, scalable solution that automates the Loan application data collection, credit appraisal and Loan Booking process. Once the data has been collected and cleansed, it will be stored in a secure database . The Computational engine (using ABC Bank proprietory algorithm ) will ascertain the eligibility .Further analytical functionality would create intelligence in the form of user dashboards , visualizations and reports (adhoc & routine).

At a minimum, the platform would have the following featured capabilities:

1. Technical Lead Searches Repository

2. If Widget Is Not Found, User (authorized ) Creates A New Widget Name Record for new user.

3. Master Widget Validates That All Fields Have Been Completed.

4. Mater Widget Confirms That No Similar Widgets Exist

5. User Confirms Record To Be Created.

1. User Searches Repository To Locate Existing Widget Description.

2. Master Widget Displays Record in authorized User Dashboard

3. User Selects Edit To Open And Modify Record

4. Master Widget Validates All Fields Completed Correctly

5. User Confirms Changes.

6. Master Widget Confirms Changes And Updates Audit Table.

7. key control measures to ensure data confidentiality

4 Business Requirements

The Requirements In This Document Are Prioritized As Follows:

Value	Rating	Description
1	Critical	This Requirement Is Critical To The Success Of The Project. The Project Will Not Be Possible Without This Requirement.
2	High	This Requirement Is High Priority, But The Project Can Be Implemented At A Bare Minimum Without This Requirement.
3	Medium	This Requirement Is Somewhat Important, As It Provides Some Value But The Project Can Proceed Without It.
4	Low	This Is A Low Priority Requirement, Or A “Nice To Have” Feature, If Time And Cost Allow It.
5	Future	This Requirement Is Out Of Scope For This Project, And Has Been Included Here For A Possible Future Release.

	Key User Stakeholders
1	CREDIT MAKER	Does Primary Checks On Loan Application ,Cross Verification Of Data With Vetted Data
1	OPERATIONS	Receives Sanction Letter And Sees It Through The Loan Booking Process
2	CREDIT CHECKER	Pre Approval Checks Done And Final Approval.Gives Approval If Criteria Met
2	FRAUD CONTROL UNIT	Vets All Document/Data /Addresses By Client
3	CREDIT CONTROL	Approves/Mitigates All Flag Raised By Credit Checker And Lead To Final Approval Or Rejestion
3	CREDIT COMMITTEE	Creates Policy Framework For Automatic (System Based) Loan Approval Or Manual Based Approval.
4	RISK CONTROL	Controls All Risk Associated With Functionting Of Approval Strategies.
5	AUDIT	Make Sures Loan Approval Process Follows RBI Guideline.

Use Cases

Reference Number	Usr01
Use Case Goal	Borrower Dash Board Widget Creation
Description	Widget Shall Take All Required Data For Loan Application And Facilitate All Documents Upload In Repository Using Temporary Id
Initiating Actor	Bank’s Client
Precondition	---
Trigger	---
Post Condition	Data Sent Computational Engine For Processing .

Reference Number	Usr02
Use Case Goal	Computational Engine Creation
Description	With Provided Proprietory/Non Proprierotory Algoritm And Text Recognition
Initiating Actor	Auto
Precondition	Client Enters Required Data
Trigger	------
Post Condition	Master widget Repository Populated With up loaded 1. Kyc , Bank Statement, GSTR Authenticated With Adhaar Based Authentications 2. Borrower Name Checked Against Legacy Database Of Defaulters 3. All Image Data (Kyc, Bank Statement, GSTR,Financial Data ) Is Populated In Converted To Text And Processed In Required Format /Field And Stored In Repository For Further Computations 4. Using Bank Proprietory Algorithm, Loan Eligibility Calculated And Stored For Further Due Diligence.

Reference Number	Usr03
Use Case Goal	Credit Maker Sub Widget Creation
Description	Credit Maker Authenticates The Data Populated ,Eligibility, Default Check,
Initiating Actor	Credit Checker
Precondition	Post Processing By Computational Engine
Trigger	---
Post Condition	1. All Data Is Manually Cross Verified/Edited 2. Transfers The Queue To Credit Checker

Reference Number	Usr 04
Use Case Goal	Credit Checker Sub Widget Creation
Description	Authenticates Eligibility If It Fits Preset Conditions Send For Approval Else Update Sub Widget With Mitigation Conditions And Send To Credit Control Queue
Initiating Actor	Credit Maker
Precondition	1. Removal Of FCU Flag From Kyc ,Banking Statement,Financial Statement 2.
Trigger
Post Condition	1.Post Automatic Approval Sanction Letter Generated 2. Sanction Condition And Important Document To Be Collected In Original . 3. If Mitigation Conditions Given Then Transferred To Credit Control Queue

Reference Number	Usr 05
Use Case Goal	Fraud Control (Fcu) Sub Widget Creation
Description	1. Authenticates All Uploaded Documents Details With Industry Shared Database(Fraud List), Verifies Business 2. Post Sanction Letter ,Receives All Required Checklist Document In Original .
Initiating Actor	Credit maker
Precondition	Al data verified with uploaded documents
Trigger	Transfer of queue from Credit maker
Post Condition	1. Logs Flag If Any Suspicion With Any Document /Details /Data 2. Post Sanction Letter ,Receives All Required Checklist Document In Original And Authenticates Them

Reference Number	Usr06
Use Case Goal	Credit Control Sub Widget Creation
Description	If Applicable Decides On Applicable Mitigation To Loan Approval
Initiating Actor	Credit Checker
Precondition	1. Credit Checker Has Given Required Mitigation List And Pre Condition Checklist To Loan Approval 2.No flag by FCU
Trigger
Post Condition	1. If Approved , Sanction Letter Generated 2. Sanction Condition And Important Document To Be Collected In Original . 3. If Mitigation Conditions Given Then Transferred To Credit Control Queue

Reference Number	Usr 07
Use Case Goal	Operation Sub Widget Creation
Description	Systems Generates 1. All Conditions Be Met ,2. Checklist ,3. Borrower Data 4. Sanction Letter Under Various Tab On Sub Widget
Initiating Actor	Credit Control /Credit Checker
Precondition	All Fcu Flag Removed
Trigger	Generation Of Sanction Letter
Post Condition	1. Receieves All Document From FCU In Original /Photocopy (Defined By RBI Guideline) 2. Enters /Scan All Document In System 3. Books loan only when all flag closed from FCU/RISK or mitigation condition met.(read specific function provided checklist)

Reference Number	Usr 08
Use Case Goal	Audit Sub Widget Creation
Description	Has Visibility On 1. Borrower Kyc 2. Application 3. Action Taken By Fcu 4. All Change Log Details 5. All Document Uploaded By Operation 5. Sanction Terms And Related Mitigation Details
Initiating Actor	Completion Of USE CASE –Usr 07
Precondition	Loan Is Booked By Operation ,Closure Of Operation Queue Post Loan Booking
Trigger	Loan Booking
Post Condition	1. Can Flag Any Change Log For Justification Under Audit Directive Policy 2. Any Flag Raised In Any Change Log Need To Be Closed By Respective Sub Widget User.

Reference Number	Usr 09
Use Case Goal	Risk Sub Widget Creation
Description	Dashboard housing /Creation Of Framework Of Loan Policy Guideline (Except Eligibility Calculation) , It Creates Reference Point For All New Master Widget Data Point Created In Repository.
Initiating Actor	Completion Of USE CASE –Usr 06
Precondition	Loan is approved /san
Trigger	Any deviation in master widget data versus prest policy framework.
Post Condition	1. Flag created on severity of deviation 2. Risk can provide conditional flag removal scenarios/mitigants /documents etc .which operations will update before Loan booking

4.1 Functional Requirements

Req#	Priority	Description	Rationale	Use Case Reference		Impacted Stakeholders
General / Base Functionality
FR-G-001	1	Creation Of Borrower UI Sub Widget Taking Input, I.E. Application Details ,Kyc,Other Financial Image Uploads	Creates Primary Database To Workon	Usr01		Development Teams Infrastructure Engineers
FR-G-002	1	A New Master Widget Repository Shall Be Created To House The New Application Records And Links To The Widget Objects.	Single Repository Simplifies Management Of Widget Development	Usr02		Development Teams Infrastructure Engineers
FR-G-003	2	A Widget Shall Be Defined In The Repository Via A Unique Identifier And Name Combination.	ID+Name Eliminates Duplicate Widget Name Records,Across Other Credit Product Gamut Of Client	Usr02		Development Teams Infrastructure Engineers
FR-G-004	1	Development Of A Computational Engine Taking Input From Client Sub Widget (UI) ,Performing Kyc Authentication And Image Processing And Eligibility Calculations	Translate Data To Required Format For Easy Reference	Usr02		Development Teams Infrastructure Engineers
FR-G-005	1	Post Data Processing In Computational Engine ,Master Widget Repository Created . Shall Have Queue System I.E. When One User Is Performing A Task On Master Widget ,Other User In Hierarchy Is NOT Able To Make Changes .At All Time Queue User To Be Visible To All Hierarchy User.	Data Point Created To Further Work On Traceability Of Application	Usr02		Development Teams Infrastructure Engineers
FR-G-006	2	Creation Of Master Widget Queue Under Credit Checker Hierarchy (Automatic Function)	Will Help In Hands Off Of Loan Application From One Function To Other	Usr03		Development Teams
FR-G-007	1	Sub Widget For Credit Maker To Facilitate Cross Verify,Edit,Provide Additional Data .All Changes Saved In Master Widget Repository And Transfer Queue To FCU (Fraud Control) And Credit Checker At Same Instant	Data Validation And Hands-Off To Other Function	Usr02		Development Teams Infrastructure Engineers
FR-G-008	1	Creation Of Framework Of Loan Policy Guideline (Except Eligibility Calculation) , It Creates Reference Point For All New Master Widget Data Point Created In Repository.	Audit Compliance	Usr09		Development Teams
FR-G-008	1	Sub Widget For Credit Checker, To Verifies All Computational Data With Provided Data /Documents.With All Criteria Being Met Loan Sanctioned .	Data integrity	Usr04		Development Teams
FR-G-009	1	Sub Widget For Credit Control /Risk .Sub Widget Display Any Breach In Policy , Its Control Measure And Approvals Required	Data Provision To Function And Response Entry With Action Course Implements	Usr06		Development Teams
FR-G-0010	1	Sub Widget For Operation To Facilitate Loan Booking	Closure Of Loan Application	Usr07		Development Teams
FR-G-0011	1	Audit Sub Widget To Extract All Required Data From Master Repository	Data Provision To Audit Function Under Rbi Regulations	Usr08		Development Teams
Security Requirements
FR-S-001	2	.Initial dashboard of Master widget shall take Input From Computational Engine.	Maintain Data Integrity	Usr02		Development Teams
FR-S-002	2	Master Widget Repository Shall Have Hierarchy Based Change Authority.I.E. Changes/Comment Made In Master Widget By Senior Hierarchy Cannot Be Changed By Lower Level Authority.	General Audit Guideline Data And Function Integrity		Usr08	Development Teams
FR-S-003	1	FCU (I.E.Fraud Control) Shall Be Able To Flag Any Uploaded Document With Visibility Across All Hierarchy. Flag Can Be Created Closed Only By FCU	General Risk And Audit Guidelines		Usr05	Development Teams Infrastructure Engineers
FR-S-005	1	FCU (I.E.Fraud Control) Shall Be Able To Flag Any Uploaded Document Operations With Visibility Across All Hierarchy. Flag Can Be Created Closed Only By FCU	Security Control		Usr05	Development Teams
FR-S-005	1	Master Widget Cannot Be Moved From Operation To Loan Booking Stage , Without FCU Flag Being Closed	Compliance		Usr05	Development Teams
Reporting Requirements
FR-R-001	2	Master Widget Repository Shall Log Every Changes ,Made With Time And Username Display.	General Audit Guideline	Usr08		Development Teams
FR-R-002	2	Generation Of Report Having Details On Each Master Widget ,i.e.Loan Amount Applicant ,Current Status Etc	Traceability Of Borrower File	Usr08		Development Teams

Usability Requirements
FR-U-001	1	BORROWER Interface For The Repository Shall Be Responsive, Allowing For Proper Display On Tablet, Laptop, And Desktop Devices.	Device agonistic UI	Usr01		Development Teams
FR-U-002	2	Borrower Interface Shall Allow –E-Signing Of All Document Uploaded	Authentication	Usr02		Development Teams
Fr-U-003	2	All Sub Widget Should Have Ui Permitting Biometric Sign-In Of Users	Security	Usr02		Development Teams
Fr-U-004	2	Operation Sub Widget UI Should Have Multiple Tab Options ,Under Sub Header I.E. Sanction Letter, Checklist With Document Upload Option, Fcu Report,Uploaded Documents	Easy Mangement /Traceability	Usr07		Development Teams

Audit Requirements
FR-A-001	1	Master Widget Repository Shall Have Hierarchy Based Change Authority.i.e. Changes/Comment Made In Master Widget By Senior Hierarchy Cannot Be Changed By Lower Level Authority.	General Audit Guideline	Usr08		Development Teams
FR-A-002	1	Any Change To A Widget Name Record Shall Be Appended With User ID And Date/Time Stamp.	Traceability	Usr08		Development Teams

4.2 Non-Functional Requirements

ID	Requirement
NFR-001	The Widget master Repository Shall be able to handle at least N users and minimum of M Borrowers Concurrently.
NFR-002	The Widget master Repository Shall Be Designated At Level 2 For Availability And SLA Purposes.
NFR-003	Availability - At the minimum, the platform has to be available to users with official working hours in India.
NFR-004	Borrower dashboard/UI /webpage should load within 2 seconds
NFR-005

5 Appendices

5.1 List Of Acronyms and term definitions

a) Fcu – Fraud control unit

b) Borrower: An person applying for loan facility

c) User – any employee of the bank

d) Flag – raising a , doubt /concern, on data or documents or process

e) Ui- user interface .

f) GSTR- The Goods and Services Tax Return is a document that each registered tax payer needs to file every month/quarter. It must contain the details of all sales and supply of goods and services made by the tax payer during the tax period.

g) Loan booking- completion of loan sanction process .Post this process Borrower account debited with loan amount.

Search This Blog

ARSHAD ALI

Business Requirements Document (BRD)-Los for fintech co