SU+ @ Strathmore University Library        Electronic Theses and Dissertations     This work is availed for free and open access by Strathmore University Library.   It has been accepted for digital distribution by an authorized administrator of SU+ @Strathmore University. For more information, please contact library@strathmore.edu     2020 A Centralized credit scoring prototype for micro lending institutions in Kenya Karingithi, Law Maina  Faculty of Information Technology   Strathmore University    Recommended Citation  Karingithi, L. M. (2020). A Centralized credit scoring prototype for micro lending institutions in Kenya [Thesis,  Strathmore University]. http://hdl.handle.net/11071/12172  Follow this and additional works at: http://hdl.handle.net/11071/12172      A Centralized Credit Scoring Prototype for Microlending Institutions in Kenya By 079176 Law Karingithi Maina Faculty of Information Technology Strathmore University A dissertation submitted to the faculty of information technology in partial fulfillment of the requirements for the award of a Degree in Masters in Mobile Telecommunications and Innovation Submitted: June 2020 ii Declaration I declare that this work has not been previously submitted and approved for the award of a degree by this or any other University. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made in the thesis itself. © No part of this thesis may be reproduced without the permission of the author and Strathmore University Student’s Name: Law Karingithi Maina Signature:__________________________ Date: _____________________________ Approval The thesis of a centralized credit scoring prototype for microlending institutions in Kenya was reviewed and approved by the following: Dr. Bernard Shibwabo, Senior Lecturer, Faculty of Information Technology, Strathmore University Dr. Joseph Orero, Dean, Faculty of Information Technology, Strathmore University Dr. Bernard Shibwabo, Director of Graduate Studies, Strathmore University iii Abstract Microlending involves giving small loans to people in need. Usually, these loans are issued to entrepreneurs or those who need extra cash to either expand their businesses or for personal use. Digital lending is becoming a leading source of credit especially to low-income citizens with minimal or no financial footprints in Kenya and other parts of the world. It has quickly become the default way for lenders to service loan requests from borrowers due to the convenience it brings about as well as the increased number of requests that can be processed compared to the traditional way that required quite an amount of paper work. As the number of lending companies grows, there is the need to standardize the credit scoring process and maintain an updated credit activity log for every user. This ensures that lenders are always aware of any other unsettled debts a borrower might have and provides them with the most recent information to assess the risk they face by lending to a borrower. The proposed solution which is a representational state transfer (REST) based web service allows lenders to submit details of loans they have approved and issued to a borrower. The information is used to generate and keep track of the user’s credit score and amount of risk lenders face should they consider to lend to the user. Agile development methodology was used to develop a robust credit scoring prototype and an Android mobile application. The final prototype was tested to ensure that the requirements were met and the functionality working as required. Results of the tests showed the system was able to generate user credit scores and differentiate between good and bad borrowers at an accuracy level of 92%. The average response time for querying a user’s credit score was slightly below a second and this allows lenders to get a response form the system almost instantly. During tests conducted, no system failure or downtime was experienced. Keywords: Microlending, Credit scoring, Representational state transfer, Android iv Table of Contents DECLARATION ..................................................................................................................................................... II ABSTRACT ........................................................................................................................................................... III TABLE OF CONTENTS ..................................................................................................................................... IV LIST OF FIGURES ............................................................................................................................................. VII LIST OF TABLES ............................................................................................................................................. VIII LIST OF EQUATIONS ........................................................................................................................................ IX ABBREVIATIONS AND ACRONYMS .............................................................................................................. X DEFINITION OF TERMS................................................................................................................................... XI CHAPTER 1: INTRODUCTION .......................................................................................................................... 1 1.1 BACKGROUND ......................................................................................................................................... 1 1.2 STATEMENT OF THE PROBLEM ................................................................................................................ 2 1.3 AIM .......................................................................................................................................................... 3 1.4 OBJECTIVES ............................................................................................................................................. 3 1.5 RESEARCH QUESTIONS ............................................................................................................................ 3 1.6 SCOPE OF THE STUDY .............................................................................................................................. 3 1.7 SIGNIFICANCE OF THE STUDY ................................................................................................................. 4 CHAPTER 2: LITERATURE REVIEW .............................................................................................................. 5 2.1 OVERVIEW ............................................................................................................................................... 5 2.2 CREDIT SCORING ..................................................................................................................................... 5 2.3 COMMON TECHNIQUES USED TO DETERMINE CREDIT SCORES .............................................................. 6 2.3.1 Internal Credit History Assessment ................................................................................................... 6 2.3.2 Credit Reference Bureau (CRB) Checks ........................................................................................... 7 2.3.3 FICO Credit Scores ............................................................................................................................ 7 2.4 FACTORS CONSIDERED WHEN DETERMINING CREDIT SCORES .............................................................. 8 2.4.1 Loan History and Repayment ............................................................................................................ 8 2.4.2 Consistency in Borrowing and Repayment ....................................................................................... 9 2.5 THE RISK OF FLAWED CREDIT SCORING PROCESSES .............................................................................. 9 2.5.1 Credit Risk ......................................................................................................................................... 9 2.5.2 Market Risk ........................................................................................................................................ 9 2.5.3 Operational Risk .............................................................................................................................. 10 2.5.4 Liquidity Risk .................................................................................................................................. 10 2.5.5 Reputational Risk ............................................................................................................................. 10 2.5.6 Business Risk ................................................................................................................................... 10 2.5.7 Systemic Risk .................................................................................................................................. 10 2.5.8 Moral hazard .................................................................................................................................... 11 v CHAPTER 3: RESEARCH METHODOLOGY ................................................................................................ 12 3.1 INTRODUCTION ...................................................................................................................................... 12 3.2 AGILE SOFTWARE DEVELOPMENT METHODOLOGY ............................................................................. 12 3.2.1 Scope out and Prioritize Projects ..................................................................................................... 13 3.2.2 Diagram Requirements for the Initial Sprint ................................................................................... 13 3.2.3 Construction / Iteration .................................................................................................................... 15 3.2.4 Release the Iteration into Production .............................................................................................. 15 3.2.5 Production and Ongoing Support .................................................................................................... 16 3.3 CONCLUSION ......................................................................................................................................... 16 CHAPTER 4: SYSTEM ANALYSIS, DESIGN AND ARCHITECTURE ..................................................... 17 4.1 INTRODUCTION ...................................................................................................................................... 17 4.2 REQUIREMENT ANALYSIS ..................................................................................................................... 17 4.2.1 Functional Requirements ................................................................................................................. 17 4.2.2 Non-functional Requirements ......................................................................................................... 18 4.3 DATA ANALYSIS .................................................................................................................................... 18 4.3.1 Degree of Response ......................................................................................................................... 18 4.3.2 User Responses ................................................................................................................................ 18 4.4 SYSTEM ARCHITECTURE ....................................................................................................................... 21 4.5 SYSTEM DESIGN .................................................................................................................................... 21 4.5.1 Use Case Diagram ........................................................................................................................... 22 4.5.2 Sequence Diagram ........................................................................................................................... 27 4.5.3 Entity Relationship Diagram ........................................................................................................... 28 4.6 CREDIT SCORING PROCESS .................................................................................................................... 28 4.6 APPLICATION MOCKUPS ........................................................................................................................ 30 4.6.1 Mobile Application Wireframes ...................................................................................................... 30 4.7 SECURITY AND DATA PROTECTION ....................................................................................................... 32 CHAPTER 5: SYSTEM IMPLEMENTATION AND TESTING ................................................................... 33 5.1 OVERVIEW ............................................................................................................................................. 33 5.2 SYSTEM IMPLEMENTATION ................................................................................................................... 33 5.2.1 Mobile Application .......................................................................................................................... 33 5.2.2 Backend System ............................................................................................................................... 35 5.3 SYSTEM TESTING ................................................................................................................................... 41 5.3.1 Introduction ...................................................................................................................................... 41 5.4 SUMMARY ............................................................................................................................................. 44 CHAPTER 6: CONCLUSION, RECOMMENDATIONS AND FUTURE WORK ...................................... 45 6.1 INTRODUCTION ...................................................................................................................................... 45 6.2 FINDINGS AND ACHIEVEMENTS ............................................................................................................. 45 6.3 RECOMMENDATION ............................................................................................................................... 45 vi 6.4 FUTURE WORK ...................................................................................................................................... 46 6.5 CONCLUSION ......................................................................................................................................... 46 REFERENCES ....................................................................................................................................................... 47 APPENDICES ........................................................................................................................................................ 50 APPENDIX A: TURNITIN REPORT ......................................................................................................................... 50 vii List of Figures Figure 4.1: Lending Channels .................................................................................................. 19  Figure 4.2: Credit Scoring Techniques .................................................................................... 20  Figure 4.3: Supported Smart Phone Operating Systems .......................................................... 20  Figure 4.4: Use Case Diagram ................................................................................................. 22  Figure 4.5: Sequence Diagram ................................................................................................. 27  Figure 4.6: Entity Relationship Diagram ................................................................................. 28  Figure 4.7 Feed-Forward Neural Network ............................................................................... 29  Figure 5.1 User Authentication ................................................................................................ 34  Figure 5.2 Mobile Application Dashboard .............................................................................. 35  Figure 5.3 Lender Management ............................................................................................... 36  Figure 5.4 User Endpoints ....................................................................................................... 37  Figure 5.5 Create New User Endpoint ..................................................................................... 37  Figure 5.6 User Credit Scoring Endpoints ............................................................................... 38  Figure 5.7 Fetch User Credit Score Endpoint .......................................................................... 38  Figure 5.8 Administrator Dashboard ....................................................................................... 39  Figure 5.9 User Logins and System Interactions ..................................................................... 40  Figure 5.10 Requests per Lender Dashboard ........................................................................... 40  Figure 5.11 User Authentication .............................................................................................. 43  Figure 5.12 User Dashboard Satisfaction ................................................................................ 43  Figure 5.13 Lender API completeness ..................................................................................... 44  viii List of Tables Table 4.1: Registration Use Case ............................................................................................. 23  Table 4.2: Login Use Case ....................................................................................................... 23  Table 4.3: View Dashboard Use Case ..................................................................................... 24  Table 4.4: Manage Lenders Use Case ...................................................................................... 24  Table 4.5: Create User Use Case ............................................................................................. 25  Table 4.6: Post User Loan Use Case ........................................................................................ 25  Table 4.7: Update User Loan Use Case ................................................................................... 26  Table 4.8: View User Credit Score Use Case .......................................................................... 26  Table 4.9: View User Credit History Use Case ....................................................................... 26  Table 5.1 User Creation Test Case .......................................................................................... 41  Table 5.2 Credit Activity Submission Test Case ..................................................................... 41  Table 5.3 Credit Score Calculation Test Case ......................................................................... 41  Table 5.4 Mobile Authentication Test Case ............................................................................ 42  Table 5.5 Manage Lenders Test Case ...................................................................................... 42  ix List of Equations Equation 4.1 Weight Scaling Function .................................................................................... 29  Equation 4.2 Activation Function ............................................................................................ 29  x Abbreviations and Acronyms API Application Programming Interface CBA Commercial Bank of Africa CGAP Consultative Group to Assist the Poor CRB Credit Reference Bureau FICO Fair Isaac Corporation FSD-Kenya Financial Sector Deepening Kenya HTTP Hyper Text Transfer Protocol SSH Secure Shell SSL Secure Sockets Layer UML Unified Modelling Language xi Definition of Terms Credit history A record of consumer’s ability to repay debts and demonstrated ability in repaying debts (Kagan, 2019). Credit score A statistical number that evaluates a consumer’s creditworthiness and is based on credit history (Kagan, 2019). Neural Network A neural network is a series of algorithms that endeavors to recognize underlying relationships in a set of data through a process that mimics the way a human brain works (Chen, 2019). 1 Chapter 1: Introduction 1.1 Background Lending has existed for many years and has taken on many forms throughout its existence. While the history of online lending is short, the roots of traditional lending can be traced back to the beginning of civilization (Atkins, 2016). Lending can be defined as the temporary giving of money or property to another person with the expectation that it will be repaid. Usually, this resource is either money or something that can be used to generate monetary value (Murray, 2019; Smith, 2019). For a long time now, the most common way to get a loan in Kenya has been to walk into a financial institution. However, with recent advancements in technology, lending has become as easy as sending the loan amount to the customer via mobile money (Sejpal & Muchiri, 2019). Unlike traditional methods that could take between one and two weeks for a loan request to be approved, current solutions such as Tala and Branch have made it instant and potential borrowers can now request for a loan, have their loan request approved and the requested loan amount transferred to their mobile money account in just a few minutes (Amery, 2018). Having a customer’s loan request approved this fast is great and is good customer experience but to achieve this, companies have had to cut down on processes that guarantee low risk lending. For example, banks need to look into a person’s financial track record and still require some form of security to cover the loan in the case that it is not paid back in full (Sejpal & Muchiri, 2019). This means that, in order to actually get a loan from a bank, the person needs to have been an active transacting member for quite some time in order to build an attractive financial trail. Mshwari, a Safaricom product works in almost a similar manner. The user needs to transact via Mpesa and save on Mshwari to increase their credit score and chances of getting a higher loan. A user’s credit score refers to a numeric value given to your credit history. It is calculated using information in a user’s credit report and indicates whether the user has a bad (low credit score) or good (high credit score) credit history (Irby, 2018). In a survey carried out by Financial Sector Deepening Kenya (FSD-Kenya) in partnership with the Central Bank of Kenya, the Kenya National Bureau of Statistics and Consultative Group to Assist the Poor (CGAP), out of 3,000 participants 27 percent had taken at least one digital loan 2 while 13 percent had not qualified for a loan due to their low credit score (Totolo, 2018). This results in a third of the total loan applicants being disqualified due to lack of an acceptable financial track record. It is however important to understand that a user not having a good credit score at the time they applied for a loan does not mean they are bad borrowers. In the current situation, every lender relies on data they collect and almost none has access to the data generated by their fellow lenders which makes it difficult to get a genuine credit score for a user. The study is aimed at building a credit scoring and aggregation prototype that lenders can use to report and query a user’s credit activity. This is accompanied by an Android mobile application that users can use to access the platform and view their credit reports to ensure they are always up to date with their credit activities. 1.2 Statement of the Problem Credit scoring is an important process to institutions and companies in the lending business. It is the process used to obtain a numerical expression based on a person’s credit history and is used as a determinant for a range within which the person qualifies for a loan (Kenton, 2019). Lending institutions and companies rely on more than just a customer’s borrowing history to make lending decisions. However, the borrowing history plays a major role in rating a person’s credit worthiness and should consist of the most recent and accurate information. In Kenya’s lending ecosystem today, users can borrow from multiple lenders and as a result borrowers have become a byproduct of mobile-based lending. They fall into the trap of living on loans and accumulate bad debt. This means that borrowers might at some point struggle to repay their loans and end up accumulating more debt which leaves them and the lender in a financial crisis. Some digital lenders are also not regulated by the Central Bank of Kenya and are not defined as a financial institutions under the current banking act, the micro finance act or the Central Bank of Kenya act (Owuor, 2019). As of such, they are not required to submit any data to the Credit Reference Bureau (CRB). This causes user lending histories retrieved from the CRB to be inaccurate and not contain data from the different lending sources used by borrowers. 3 1.3 Aim The study is aimed at developing a credit scoring prototype that microlending institutions can use to define real and unbiased credit scores based on the users’ day to day credit activities. This is coupled with a mobile application that users can access to check their credit score, learn more about how to improve it and factors that resulted to their credit score. The proposed system has a backend that exposes HTTP endpoints that lending companies can use to submit or update users borrowing and repayment activities as well as endpoints to retrieve users credit scores and borrowing histories. The backend also serves data to the user facing mobile application. To allow for maximum input and contribution from experts in the lending industry, formulas used and factors taken into consideration when generating a user’s credit score is open-sourced and made freely available to the general public. This can also ensure a transparent scoring process to both companies and users. 1.4 Objectives i.) To analyse current techniques used to determine a user credit scores ii.) To investigate factors considered when determining a user credit scores iii.) To develop and test the credit scoring prototype for micro-lending institutions in Kenya iv.) To validate that the developed credit scoring prototype generates reliable credit scores 1.5 Research Questions i.) What are the most commonly used technique to determine a user’s credit score? ii.) What factors are considered when determining a user’s credit score? iii.) How can the credit scoring prototype be designed, developed and tested to generate reliable credit scores? iv.) How can the developed credit scoring prototype be validated so as to ensure that it generates reliable credit scores? 1.6 Scope of the Study The process of credit scoring primarily involves relying on a user’s credit history to determine their credit score. The scope of this study entails creating a standard credit scoring process, disclosing necessary factors to consider when computing a user’s credit score and the 4 development of a system that lenders can use as a repository for storing borrower’s credit data which also allows them to query users credit scores and borrowing history. 1.7 Significance of the Study In Kenya, most lending companies use judgmental credit analysis to determine credit scores. This is a method of approving or denying credit based on a lender’s judgment rather than on a particular credit scoring model (Kagan, 2019). Since this method does not use credit data from other lending companies, it could potentially result in lenders denying loans to good borrowers or approving loans to bad borrowers. The importance of having a centralized repository for credit histories is that data used to build a user’s credit score is based on information from different lending institutions which results in a more realistic assessment of the borrower. The user’s borrowing history also becomes transparent to lenders and can be used for risk mitigation purposes. Although the CRB exists, lenders only report bad borrowers which makes it ineffective to determine good borrowers. The Central Bank of Kenya (CBK) has also barred unregulated mobile lenders from forwarding defaulters and stopped the blacklisting of borrowers owing less than 1,000 Kenyan shillings (Munda, 2020). Besides this, the CRB and other credit scoring systems do not expose their internal operations thus making the process none transparent. 5 Chapter 2: Literature Review 2.1 Overview In this chapter, the researcher studies different techniques used by lending companies to determine the amount lent to a borrower, factors taken into consideration and ways that companies mitigate lending to high risk borrowers. The researcher also explores several factors that should be considered when determining how much to lend and how those factors can affect a user’s credit score and credibility for debt. 2.2 Credit Scoring Credit scoring is a statistical analysis performed by lenders and financial institutions to assess a person’s creditworthiness (Kenton, 2019). It is used by lenders to determine whether to approve or decline a credit request. In developed countries, credit scores are not only used when servicing loan requests but also come into play when negotiating insurance rates, refinancing student loans, renting apartments or even buying a house (Harzog, 2018). It is therefore important to retain a good credit score throughout your financial life to ensure that you get the best services in situations where your credit score is a major contributor to the outcome. In Kenya credit scores are not used outside the lending space and will not play any role when it comes to renting houses, buying homes or insurance but will be highly considered when applying for a loan hence the need to still retain a good credit score. Credit scores are designed to make decisions easier for lenders. This helps them assess the borrower and the risk they come with. When you get a loan, lenders report your activity to credit bureaus and the data is compiled into credit reports. A computer program will read this information and decide whether the loan applicant is creditworthy or not (Pritchard, 2019). 6 2.3 Common Techniques Used to Determine Credit Scores There are numerous possible ways by which lenders can determine a user’s credit score. While most companies prefer not to disclose their techniques, the following sub-sections present some of the most commonly used techniques. i.) Internal credit history assessment ii.) Credit Reference Bureau (CRB) checks iii.) Fair Isaac Corporation (FICO) credit scores 2.3.1 Internal Credit History Assessment Internal credit history assessment is a scoring technique that is based on a user’s credit history retained by a lender. Usually, the user needs to have been an active member of the lending company for a period of time either borrowing and repaying their loans or saving with the company to build a financial trail. As mentioned in the previous chapter, M-Shwari which is a Safaricom saving and lending product is one of the lending services that determine a user’s loan limit by their saving, borrowing and loan repayment activities. The product also uses M- PESA, a mobile money transfer service by Safaricom to determine the user’s flow of money. In order to qualify for a loan with M-Shwari, the user has to be an active M-PESA subscriber for at least six months (CBA, 2013). The use of internal credit history to score users is the most common way of credit scoring in Kenya today. Most lending companies only have access to their user’s records and do not expose their credit scores to other lenders. Although this is very understandable given the nature of the business and system security loopholes creating APIs might come with, it becomes risky when a lender is not able to tell if a user has any other unsettled debts. If a user has other debts, even with the use of the lowest lendable score earlier discussed they may never repay their loan causing the lender to completely lose the funds. This could also lead to situations where borrowers take on more credit than they can manage or take out loans to pay off other loans creating a debt cycle which negatively impacts them and the lenders (Kaffenberger & Chege, 2016). 7 2.3.2 Credit Reference Bureau (CRB) Checks Credit reference bureaus are agencies where banks and other lenders submit details of users with non-performing loans. In Kenya, lenders use them to disqualify borrowers who have been blacklisted due to failure to clear previous debts. While some lenders report information to the Kenyan credit bureau, the information is often incomplete and most digital lenders are nonbanks who are not required to report data at all (Kaffenberger & Chege, 2016). This means that sometimes, users who have defaulted a previous loan could miss from the CRB leaving lenders at risk of losing money to defaulters. Fetching information from a credit bureau also requires third party system integrations which is at times a pain given the scarce documentation available. Besides that, most lenders only report on non-performing loans which makes it almost impossible to build a reliable credit history for a user. As of 2019, the Central Bank of Kenya (CBK) issued a statement that borrowers will only be considered to have defaulted after 6 months (Guguyu, 2019). 2.3.3 FICO Credit Scores Although not used in Kenya, the FICO score is one of the most popular credit scores used by lenders in the United States of America. It is generated by the Fair Isaac Corporation and is based solely on information in consumer credit reports maintained at the credit reporting agencies. FICO credit scores range between 300 and 850 with a higher score representing a lower risk. While many lenders use FICO credit scores to make lending decisions, each one determines the level of risk they find acceptable for their credit products. As much as the Fair Isaac Corporation does not disclose how exactly it generates user credit scores, below is a list of factors considered and their percentage contribution to the final score (myFICO, 2018). i.) Payment history – 35% The payment history considers whether the user has been paying past credit accounts on time which indicates the amount of risk the lender is taking on. The better the repayment history, the higher the percentage. ii.) Amount owed – 30% This indicates how much a user owes on their credit accounts. If a user is using too much of their available credit, there could be a higher chance that they will default. iii.) Length of credit history – 15% 8 The length of a user’s credit history determines how long the user has had their credit account and how long it has been since they last used it. Longer and more recent credit histories contribute to higher percentage. iv.) Credit mix – 10% Even though not necessary, the FICO score considers the user’s mix of credit cards, retail accounts, installment loans, finance company accounts and mortgages. v.) New credit – 10% FICO considers users who open several credit accounts over short periods of time as high risk especially if they do not have a long credit history which contributes to a lower percentage. 2.4 Factors Considered When Determining Credit Scores In this section the researcher looks into the 2 main factors that are considered in determining a user’s credit score. i.) Loan history (number of paid, outstanding, late payment and defaulted loans) ii.) Consistency in borrowing 2.4.1 Loan History and Repayment A borrower is assigned a good credit score when a lender believes they will pay their debt on time. On the other hand, a bad credit score implies that it is unlikely the borrower will fulfil their financial obligations with the lender in time. Usually, a borrowers credit is determined by their historical debt obligations. A borrower that has historically paid on time will be more trusted to pay their new debt on time which will in turn results in a higher credit score (Irby, 2019). Besides timely payment, the number of loans previously taken are also used to determine a user’s likeliness to pay new debt. A borrower with a consistent borrowing and repayment history will be more likely to repay new debt on time compared to one who has an inconsistent borrowing pattern. When calculating a user’s credit score, the balance of their loans which is the difference between their initial loan amounts and their current loan balance in most cases negatively affects their credit score. The lower the loan balance the better the credit score (Irby, 2019). 9 2.4.2 Consistency in Borrowing and Repayment Borrowers who have a consistent pattern of borrowing are considered to be more predictable than irregular borrowers and will in most cases have a higher credit score. In fact, FICO and VantageScore consider consistency in repayment as the most important factor when calculating credit scores contributing 35% of the total score (Medhora, 2019). 2.5 The Risk of Flawed Credit Scoring Processes Credit scoring of users is an essential process for any lending institution. It is used to mitigate risk by only lending to borrowers who are more likely to pay back the loan. According to Gangreddiwar (2015), there are several risks in the banking industry that are faced by every bank. They include; i.) Credit risk ii.) Market risk iii.) Operational risk iv.) Liquidity risk v.) Reputational risk vi.) Business risk vii.) Systemic risk viii.) Moral hazard 2.5.1 Credit Risk Credit risk is the possibility of a loss resulting from a borrower’s failure to repay a loan or meet contractual obligations (Labarre, 2019). This is most likely caused by loans, interbank transactions and can occur when a person borrows a loan and is not able to repay it. In most cases, the interest for such borrowers is increased since they are considered high risk. 2.5.2 Market Risk This is defined as the risk of losses in the bank’s trading book due to changes in equity prices, commodity prices or interest rates (Gangreddiwar, 2015). Interest rate risk, which is one of the risks in market risk is the potential losses due to fluctuations in interest rate. When the interest rate if increased for a borrower, they may not be in a position to repay the loan and may default. 10 2.5.3 Operational Risk Operational risk is the risk of losses resulting from uncertainties and hazards when a company attempts to do id day-to-day business activities. It can result from breakdowns in internal procedures, people and systems (Segal, 2019). They can occur due to human error or mistakes which include but not limited to incorrect filling of information or unintentional data leaks. With an automated credit scoring mechanism this risk is completely minimized due to the little or no human intervention. 2.5.4 Liquidity Risk This refers to risk due to lack of marketability of an investment that cannot be bought or sold quickly to prevent losses (Gangreddiwar, 2015). A wrong or faulty credit scoring process may lead to quite a huge amount of liquid cash being disbursed which may cause an institution not to have liquid cash temporarily. 2.5.5 Reputational Risk Reputational risk is a threat or danger to the good name of a business (Kenton, 2019). It is brought about when the institution gets a bad reputation either due to internal activities, rumors, bad customer support or even back customer experience. When it comes to lending, consistency in determining a user’s creditworthiness results in good customer experience and predictable system outcome by the customer. 2.5.6 Business Risk Investopedia defines business risk as the possibility that a company will have lower than anticipated profits or that it will experience loss rather than profit (Kenton, 2019). This can however be avoided with flexibility and adaptability of the business to market conditions. 2.5.7 Systemic Risk Systemic risk affects an entire industry rather than a single financial institution. It can be caused by cascading failure for example when a borrower takes a loan from one institution, is unable to pay back the loan and later takes out another loan to repay a previous loan creating a debt cycle of uncleared debt (Gangreddiwar, 2015). By centralizing a user’s credit histories, institutions can avoid this kind of risk since the credit scoring system will have complete visibility of the user’s habits and any accrued debt. 11 2.5.8 Moral hazard Moral hazard refers to risk that occurs when a financial institution or an employee of a financial institution makes the decision about how much risk to take while someone else bears the cost (Gangreddiwar, 2015). For example, if a company determines how much a borrower should be eligible for by manually going through the records, an employee might decide to overlook certain past history which might cause huge losses if the borrowers do not meet their obligation to pay back the loan. 12 Chapter 3: Research Methodology 3.1 Introduction The researcher reviews and studies the existing publications, credit scoring systems and models to efficiently come up with an approach to build a credit history aggregation system that can be used to generate credit scores. This section describes the research methodology, location of the research and data collection techniques that were used. 3.2 Agile Software Development Methodology Agile software development describes an iterative development approach that shortens the software development cycle (Hellem, 2017). Some of the reasons for using it are (Segue Technologies, 2015); i.) Transparency: It allows clients and affected parties to be involved in the development process from prioritizing features to iteration planning. ii.) Predictable delivery: By using time-boxed, fixed scheduled sprints, new features are delivered quickly and frequently. iii.) Allows for change: New or changed backlog items can be planned for in iterations providing the opportunity to introduce changes within a few weeks. iv.) User focused: By focusing features on the needs of real users, each feature incrementally delivers value. Agile development can be broken down into 6 stages (Lucidchart, 2017): i.) Scope out and prioritize projects ii.) Diagram requirements for initial sprint iii.) Construction / iteration iv.) Release the iteration into production v.) Production and ongoing support for software release vi.) Retirement 13 3.2.1 Scope out and Prioritize Projects In this phase, the business opportunity was defined as well as time and work it would take to complete the project. The entire project was broken down into smaller projects and the information used to assess technical as well as economic feasibility and decide on which projects were worth pursuing. The researcher focused on building a backend system that exposes HTTP endpoints to submit and query user credit histories and credibility as well as a mobile application for users to query information on their creditworthiness. 3.2.2 Diagram Requirements for the Initial Sprint Once the projects to be pursed had been identified, work with stakeholders to identify the requirements began. The researcher used exploratory research to get a better understanding on current credit scoring methods, some of their limitations and ways to design and develop a more accurate and reliable credit scoring system for the microlending industry. To achieve this both primary and secondary research methods were used. 3.2.2.1 Location of the Study The researcher chose Nairobi county as the location to conduct the study. This is owed to the fact that most of the microlending companies in Kenya have their headquarters and offices in Nairobi which was convenient in terms of time and resources used to conduct the study. The county also houses the largest population density in the country which turns out to be very conversant with mobile borrowing. Between March and December of 2019, 15 mobile lending companies had disbursed a total of 112 Billion Kenyan shillings to borrowers (Owino, 2019). The fact that all 15 companies are based in Nairobi only made it easier to conduct interviews for the study. 3.2.2.2 Sampling The researcher used non-probability sampling method which involved collecting data from a sample selection based on a company’s user base and ease of accessibility. Although this method may sometimes produce skewed results, it was convenient for the preliminary research and effective to assess credit scoring practices in use by the selected target sample. Judgmental sampling was used where the researcher selected the microlending companies with the assumption that bigger companies have more diverse methods of credit scoring as opposed to the smaller ones. Out of the top 15 lending companies that were responsible for disbursing 112 14 Billion Kenyan shilling in 2019, 6 of them were either banks or products owned by banks. Due to their closed nature, the researcher excluded them from the potential interview sample to remain with 9 small and medium-sized enterprises which are generally more open to interviews on their internal processes. All 9 lenders were available for interviews. 3.2.2.3 Data Collection The importance of data collection is to give an indication on the viability of the entire project. In this research, data collection was accomplished through interviews, and documentation review. Interviews conducted with different startups shed light into their operations and the different point of views when it comes to the lending process. 3.2.2.4 Secondary Research Methods Secondary research involved gathering information from previously published research. A detailed review of existing documents and materials pertaining to credit scoring and determining user creditworthiness was done to internalize the idea behind credit scoring. This involved reading through blog posts and articles by lending companies and analysts in the financial sector. The publications provided information on various ways credit scoring is achieved, different factors companies take into account and how they contribute to the final score. 3.2.2.5 Design This stage involved the use of diagrams to represent the functionality and infrastructure of the system. The researcher used a sequence diagram to detail how operations are carried out. A sequence diagram is time focused and shows the order of interaction visually to show what messages are sent and when. The purpose of the sequence diagram is to (Visual Paradigm, 2020): i.) Model high-level interaction between active objects in a system ii.) Model the interaction between object instances within the collaboration to realizes system the user case and operations iii.) Model generic interaction and show possible paths of interaction between the instances The researcher also used an entity relationship diagram (ERD) to clearly display the system entities and their internal relationships. 15 3.2.3 Construction / Iteration After definition of the project requirements and completing the system design, the development work began. The product underwent various rounds of revisions and the first iteration only included the bare minimum functionality. However, the process involved additional sprints that enable expansion of the overall product. The system was developed based on the interactions settled on during the design phase. It involved developing the end-user mobile application as well as the backend credit aggregation and scoring backend. The stacks and tools used for the prototype include: i.) Android Application: The mobile application was built for android devices. ii.) REST Backend: The backend was built predominantly in Python. It exposes HTTP endpoints used to submit and query user credit activities and credit scores. iii.) Database: A PostgreSQL database was used to store all system data that requires persistence. It is an opensource database with extensive features to handle all current system requirements. iv.) Cache: The introduction of a cache reduces queries made to the database for data that does not change frequently. Redis cache was used to fulfill this requirements. 3.2.4 Release the Iteration into Production This stage involved quality assurance testing to ensure all defects were addressed, finalizing system and user documentation and finally releasing the iteration into production. There were different kinds of tests done which can generally be categorized into manual and automated testing. Manual testing is done in person by clicking through the application or interacting using appropriate tooling. Automated tests on the other hand are performed by a machine that executes a script that has been written in advance (Pettit, 2020). Tests that were conducted include: i.) Integration tests: These ensured that the different modules of the application worked well together. For example database interaction and data exchange between services. ii.) Functional testing: These tests focused on the business requirements of the application. They verified the output of actions without checking any of the intermediate states of the system. iii.) End-to-End tests: These are tests meant to mimic user behavior with the system to ensure various user flows worked as expected. 16 3.2.5 Production and Ongoing Support This stage involved providing support for the software release. It entails keeping the system running smoothly and showing users how to use it. This phase ends when support has ended or when the release is planned for retirement. During this phase, users interacted with the system and got acquainted with the features and functionalities it offers. 3.3 Conclusion This chapter looks at the various methods used to gather information on the subject matter. The methodology allows the researcher have a better understanding of how different lending companies and institutions score their users as well as come up with a clear way to build a prototype that can better perform the process. 17 Chapter 4: System Analysis, Design and Architecture 4.1 Introduction In this chapter, the researcher looks into the analysis, design and system architecture based on requirements and methodology proposed in the previous chapter. This was achieved through sequence and entity relationship diagrams. 4.2 Requirement Analysis Requirements can be split into functional and non-functional requirements. Functional requirements are specifications to business needs. They include business rules, process flow, and calculations. Non-functional requirements on the other hand capture anything not in the functional requirements. They include operational characteristics, architecture, technical specifications and design (Spacey, 2016). 4.2.1 Functional Requirements The functional requirements describe the process flow and activities that are carried out within the system. They are well formed requirements that describe functions such that they are consistent, cohesive, atomic and verifiable (Spacey, 2016). In the proposed system, these are: i.) Lenders should be able submit user borrowing and repayment activities to the system ii.) Lenders should be able to query user credit scores and credit histories form the system iii.) Users should be able to register and log into the platform iv.) Users should be able to check their credit score and factors that contributed to it To ensure maximum system uptime and continuous response, the system employs business rules to handle errors, failures and any suspicious activity identified by the system. Some of these include: i.) If the system receives an invalid request, respond with an error 400 ii.) If the system receives the same invalid request 3 times, blacklist the client machine from accessing the resource for a minimum of 30 minutes iii.) If a service reports an error between 500 and 599, raise an administrator alert iv.) If a response to a client machine fails, cache the response for a maximum of 1 minute and use it when the client retries the request 18 4.2.2 Non-functional Requirements Non-functional requirements are considered to be requirements that are not essential to the system but play a role in ensuring the system is completely functional. As earlier noted, they cover the operations of the system as well as technical specifications. These include: i.) The mobile application should run on all Android version 4.2 devices and above ii.) The mobile application should be easy to use and navigate iii.) The backend system should ensure data integrity, consistency and security iv.) The system APIs should be well documented to allow for easy onboarding of lenders v.) The system should be able to handle multiple concurrent requests with reasonable speed vi.) The system should have robust error and failure notification handling 4.3 Data Analysis Data collection was done solely via interviews and documentation review. Interviews were conducted one on a one basis with representatives from the sampled companies. All 9 respondents from the lending companies selected where available for interviews and agreed to participate in the testing and soft launch of the credit aggregation and scoring prototype. 4.3.1 Degree of Response Although the target sample was only 9 companies, the number of lending companies is more than that. However, the research was limited by time constraints and inaccessibility to all potential companies. 4.3.2 User Responses All 9 companies were accessible and a representative from each one of them availed themselves for the interview resulting in a 100% response rate. The interviews conducted during the research provided the following feedback. 4.3.2.1 Lending Channels Identifying the lending channels used by each lender was meant to find out what digital lending channels are more favorable to the lender and why. Out of the 9 respondents, 7 of them use smartphone mobile applications that are only available on Android operating system. The other 2 use Unstructured Supplementary Service Data (USSD) which has the potential to capture 100% of the market since users do not need smart phones to use any of the services provided 19 by the lender. Figure 4.1 shows the distribution between smart phone and USSD lending channels. Figure 4.1: Lending Channels 4.3.2.2 Credit Scoring Techniques Most lenders if not all perform user credit scoring. Based on the interview results, all 9 lenders make use of internal credit history assessment and 4 out of the 9 respondents also rely on data from the Credit Reference Bureau (CRB) to determine if a loan request should be approved or declined. The internal credit history assessment is performed differently for each company and a user credit score may differ between lenders. Figure 4.2 shows the usage of the 2 main techniques used for credit scoring. 78% 22% Lending Channels Smart phones USSD 20 Figure 4.2: Credit Scoring Techniques 4.3.2.3 Supported Smart Phone Operating Systems All 7 lenders that lend via mobile applications only support Android operating system. This is largely due to the fact that the Android operating system allows access to the user’s stored data if the user has enabled permissions for the same. This makes data mining easier and less of a hustle since the lender’s application gets access to the information it needs to assess the user. Figure 4.3 shows the distribution of smart phone operating systems supported by the lenders. Figure 4.3: Supported Smart Phone Operating Systems 100% 44% 0% 20% 40% 60% 80% 100% 120% Credit Scoring Techniques Internal assessment CRB checks 100% Supported Smart Phone Operating Systems Android iOS Windows 21 4.3.2.4 Limitations of Current Credit Scoring Process After interviewing representatives from all 9 companies on the limitations they face with their current credit scoring processes, the most common limitation that cut across all lenders was the lack of visibility of user activities beyond their system. While this should be a major factor while scoring borrowers, the lack of an interconnecting platform between lenders makes it impossible to achieve this. 4.4 System Architecture The proposed credit scoring prototype actors consist of: i.) Users: Anyone with the Android application, can register, log into the platform and check their credit score summary ii.) Lender: Lending company that has been registered to use the credit scoring platform iii.) Administrator: A system user with superuser or administrative rights to the system When a user requests for a loan from a lender, the lender queries the credit scoring system to either retrieve the user’s credit score or credit activities. The lender assesses the user and decides on whether the risk to lend is one they are willing to take on. If the loan is approved, the lender then reports that to the credit scoring system where it is recorded and the users credit score and risk factor is updated. Users can also use the mobile application to check their credit score, learn more about why they have been assigned that credit score and ways to ensure that their credit score is always an advantage to them as shown in Figure 4.5. 4.5 System Design A use case diagram was used to visualize the user’s interaction with the system and show the relationship between the user and the different use cases in which they are involved. It was also used to identify the different types of system users. A sequence diagram was also used to show object interactions within a time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry the functionality of the scenario. With the system using a relational database for data persistence, an entity relationship diagram was used to show the relationships of entity sets stored in the database. 22 4.5.1 Use Case Diagram Figure 4.4 shows the users (borrower), administers and lenders interactions with the system. Figure 4.4: Use Case Diagram 23 4.5.1.1 User Case Description Table 4.1 shows the mobile application registration process. It describes any prior steps a user needs to have taken to successfully register on the application. Table 4.1: Registration Use Case Use Case Name Registration Primary actor User Description A user wants to access the application dashboard Precondition A user has downloaded the application and has a valid phone number Postcondition User should be able to access the dashboard Table 4.2 shows the login process for the mobile application after successful registration. It describes steps a user should take before being able to log into the application and what they should expect on successful login. Table 4.2: Login Use Case Use Case Name Login Primary actor User Description A user wants to access the application dashboard Precondition User has successfully registered Postcondition User should be able to login and access dashboard 24 Table 4.3 shows what a user should view after successful login. It describes steps that a user is required to have taken before being able to access their dashboard. Table 4.3: View Dashboard Use Case Use Case Name View Dashboard Primary actor User Description User wants to view their credit history, credit score and potential lenders Precondition User has successfully logged into the application Postcondition User should be able to access the application dashboard, view their credit score and credit history Table 4.4 shows the operations an administrator can perform while managing lender accounts and describes prior actions needed to enable them manage lenders. Table 4.4: Manage Lenders Use Case Use Case Name Manage Lenders Primary actor Administrator Description Administrator wants to add, suspend or deactivate lenders Precondition Administrator has successfully logged into the system with administrative rights Postcondition Administrator should be able to add, suspend or deactivate lender accounts 25 Table 4.5 shows the user creation process by a lender. This is necessary when a lender needs to post a user’s credit activity before the user has registered on the platform. It describes the requirements and prior conditions. Table 4.5: Create User Use Case Use Case Name Create User Primary actor Lender Description Lender wants to create a user account and post credit activity Precondition Lender has access to API endpoints to perform the action Postcondition Lender should be able to create a user account Table 4.6 shows the process of a lender posting loan activity of a user. It describes any activities that require to have taken place before the lender can successfully post a user’s loan activity. Table 4.6: Post User Loan Use Case Use Case Name Post User Loan Primary actor Lender Description Lender wants to post loan details of a loan approved for a user Precondition Lender has created the user account Postcondition Lender should be able to post the user loan 26 Table 4.7 shows the process of a lender updating a previously posted loan activity. It describes activities that should have taken place before this is possible. Table 4.7: Update User Loan Use Case Use Case Name Update User Loan Primary actor Lender Description Lender wants to update the loan details of a user account Precondition Lender has posted initial loan details Postcondition Lenders should be able to update loan details Table 4.8 shows the process of a lender retrieving a user’s credit score and describes conditions that should be met before they can perform the action. Table 4.8: View User Credit Score Use Case Use Case Name View User Credit Score Primary actor Lender Description Lender wants to view a user’s credit score Precondition Lender is authenticated to use system APIs Postcondition Lender should be able to view user credit score Table 4.9 shows the process of a lender querying a user’s credit history. It describes the precondition required and action that should occur if the precondition for this action is met. Table 4.9: View User Credit History Use Case Use Case Name View User Credit History Primary actor Lender Description Lender wants to view a user’s credit history Precondition Lender is authenticated to use system APIs Postcondition Lender should be able to view user credit history 27 4.5.2 Sequence Diagram Figure 4.5 shows the sequence of interactions and exchange of messages between the users of the mobile application, lending companies and the credit aggregation and scoring prototype. Figure 4.5: Sequence Diagram 28 4.5.3 Entity Relationship Diagram The backing database of the credit scoring prototype is based on a relational database. Figure 4.6 shows the core table structures and the relationships between them the users (borrowers) and lenders. Figure 4.6: Entity Relationship Diagram 4.6 Credit Scoring Process The credit scoring process begins when a borrower’s first credit activity is submitted. When this happens the system checks for the borrower’s previous credit history and uses it to calculate their credit score. The credit score is calculated by passing the credit history into a feed- forwards neural network that contains a single hidden layer with 5 neurons each with a weight between 1 and 5 to produce a single value credit score. The neurons calculate the borrower’s credibility based on consistency in amounts borrowed, timely repayments, ratio of performing to non-performing loans and the consistency in the increase in amounts borrowed. 29 Figure 4.7 Feed-Forward Neural Network The neural network is composed of a single input layer, a single hidden layer and an output layer of one neuron. The input layer accepts inputs from a borrower’s credit history and weighs them based on the weight configured on the system. Equation 5.1 shows the function applied to the input data before passing it to the hidden layer. The function is meant to either scale the weight up or down depending on the input value which directly affects the credit score computation function. It helps in determining what input should be considered more than the other. Equation 4.1 Weight Scaling Function 𝑓 𝑤𝑒𝑖𝑔ℎ𝑡 ∗ 𝑖𝑛𝑝𝑢𝑡 Once the weights have been scaled, the original inputs and the scaled weights are then passed on to the hidden layer and an activation function applied on each neuron. These are then summed up to produce the final credit score. Equation 4.2 Activation Function 𝑓 𝑤𝑒𝑖𝑔ℎ𝑡1 ∗ 𝑖𝑛𝑝𝑢𝑡1 ∗ % 𝑣𝑎𝑙𝑢𝑒 𝑤𝑒𝑖𝑔ℎ𝑡2 ∗ 𝑖𝑛𝑝𝑢𝑡2 ∗ %𝑣𝑎𝑙𝑢𝑒 . . 30 4.6 Application Mockups 4.6.1 Mobile Application Wireframes After the user has downloaded the application onto their Android device, they should be presented with a login screen where they are required to enter their phone number and password for verification as shown in Figure 4.7. On pressing the Login button, the phone number is authenticated against the password provided and an authentication code sent to their device. The application should detect the code and authenticate the user redirecting them to the dashboard that should display their credit score, number of loans taken, non-performing loans and any other details relevant to their account. Figure 4.8: Application Login 31 On successful authentication, the borrower is presented with a summary dashboard displaying their credit score, loan summary and potential lenders who can lend to them based on the their current credit score as shown in Figure 4.8. This ensures that the borrower is always aware of their creditworthiness, any unsettled debts and makes it easy for them to access more credit since the system lets them know of lenders who can lend to them. Figure 4.9: Application Dashboard Lenders can also use the same mobile application to access the company account. On authentication, they are presented with a dashboard summary containing the total number of loans, active and non-performing loans as well as the number of potential borrowers based on their previous lending history. 32 Figure 4.10 Lender Account Dashboard 4.7 Security and Data Protection The backend system is designed to accepts requests via Secure Sockets Layer (SSL) which ensures that all communication between the server and client applications is encrypted such that the data being exchanged is not human readable after encryption. It also makes it difficult to decrypt the information without knowledge of the certificates being used on the server. Access to the database is also restricted and uses Secure Shell (SSH) for authentication. This means that the public key of the client machine accessing the database must have been added to the database server beforehand. Due to the data aggregation nature of the system, a user identifier is required for lenders to submit or query a user’s credit activity. In Kenya, lending platforms use the user’s phone number as be primary identifier. To protect user data that can be used to identify them, the user phone number is hashed using SHA3-224 algorithm before being persisted to the database ensuring that the identity of the users remains concealed. 33 Chapter 5: System Implementation and Testing 5.1 Overview This chapter focuses on the actual implementation and testing of the proposed credit scoring prototype. It looks at the mobile application user’s use to access the system and the backend services used for credit scoring, generating user dashboards as well as serving public APIs used by lenders to interact with the system. The chapter also looks at the tests that were carried out to ensure that both the mobile application and backend system met all requirements. 5.2 System Implementation The Android mobile application was developed using technologies that support native application development. The development language used was Java while the interface layouts were designed in XML with the target version being Android version 4.2. The backend REST services were built in Python with a PostgreSQL backed database and a Redis cache. 5.2.1 Mobile Application The mobile application was developed for use by the public. It requires an Android device, internet connectivity and enables users view their dashboard which displays their credit score, loan history if any and suggests lenders who can lend to them with their current credit score making the process of accessing credit easier. It also ensures the user is always up to date with their credit activity and periodically alerts them of loans they are yet to repay all from a single application. 5.2.1.1 User Authentication Once the user has downloaded their application onto their device, they are required to log in using their phone number. Firebase phone number authentication is used for both user authentication as well as state retention for all authenticated users. Figure 5.1 shows the authentication screen presented to the user. 34 Figure 5.1 User Authentication 5.2.1.2 Application Dashboard After successful authentication, the borrower is presented with a dashboard displaying their credit score, any unpaid loans, a list of lenders they can acquire credit from as well as any other information that relates to their account. Figure 5.2 shows the dashboard presented to the user after authentication. 35 Figure 5.2 Mobile Application Dashboard 5.2.2 Backend System The backend system was developed in Python with a PostgreSQL database and a supporting Redis cache. Administrative functionality was built using the Django framework and Swagger for API documentation. 5.2.2.1 Credit Scoring Implementation The user credit scoring micro-service users PyTorch to create a feed forward neural network. PyTorch is an open source machine learning framework built by Facebook. The researcher uses it to accelerate the path from research prototyping to the production deployment. The neural network contains a forward layer that takes in loan inputs and uses the weight scaling and activation functions as described in Equations 4.1 and 4.2 respectively. During the initial phase, the researcher does not define a loss function due to the lack of a backpropagation mechanism and instead updates the weights and gradient in the activation function are updated as need be. 36 5.2.2.2 Manage Lenders A system administrator can manage lenders by creating new lender accounts, disabling existing ones or even suspending them if required. Figure 5.3 shows the user interface used to update a lender’s details. Figure 5.3 Lender Management 5.2.2.3 Lender Interaction Lenders can access their account dashboard via the mobile application as shown in Figure 4.9. However, the mobile application is meant for aggregate data and statistics on how the lender is performing on the platform. To query a borrower’s credit score or submit a credit activity, lenders need to interact with the system by making HTTP requests. Keeping in mind that each lender has their own database of preference, the system does not support querying data from these databases. It is left to the lender to ensure that they report every activity to ensure that they get the best out of the system. This means that when a lender approves or declines a loan request, they should use the endpoints provided to submit the action. Once a loan is repaid, they should also ensure that they post the activity. This will ensure that all lenders have the most resent information on a borrower. Figure 5.4 and Figure 5.5 show some of the user and credit score endpoints available to lenders. 37 Figure 5.4 User Endpoints Clicking on an endpoint expands it to show the endpoint description as well as any values that should be passed when initiating the call to the HTTP call to the API. Figure 5.6 shows the details of the endpoint used to create a new user account. Figure 5.5 Create New User Endpoint 38 Figure 5.6 User Credit Scoring Endpoints Similar to the user endpoints and all other endpoints provided by the API, clicking on the endpoint to fetch a borrower’s credit score will expand the documentation for the endpoint. Figure 5.8 shows the expanded section. Figure 5.7 Fetch User Credit Score Endpoint 39 5.2.2.4 System Analytics and Usage System administrators have access to all system data. They have the rights to view all lender and user accounts. Besides that, they can also see credit scores generate by the system for monitoring and analytical purposes. Figure 5.6 shows the dashboard that can be used for this. Figure 5.8 Administrator Dashboard The administrator can click on a summary to display a graphical representation. Figure 5.10 shows the number of users who logged in via the mobile application against the number of system interactions. This helps the administrators gather information on when users are more interested in using the application which could directly translate to the period of time when borrowers are looking for credit. 40 Figure 5.9 User Logins and System Interactions Administrators also have visibility of the requests being made by lenders. This is important to identify lenders who are spamming the system which could potentially cause a denial of service thus rendering the system unavailable. Figure 5.11 shows the requests per lender dashboard that shows the number of requests that have been made by a lender. Figure 5.10 Requests per Lender Dashboard 41 5.3 System Testing 5.3.1 Introduction This section describes the tests performed on both the web and mobile application. The researcher focused API testing and acceptance testing. The API tests achieved an accuracy level of 92 percent experiencing no failure or downtime. System response was continuously tested and was recorded to be 900 milliseconds on average. 5.3.1.1 API Testing API testing is a testing technique that validates an application programming interface. The purpose is to check the functionality, reliability, performance and security of the programming interface. The main concentration is on application logic Table 5.1 User Creation Test Case Test Case Create User Description Lender creates user account to allow submission of user credit activity Results Account successfully created Pass / Fail Pass Table 5.2 Credit Activity Submission Test Case Test Case Submit user credit activity Description Lender submits user credit activity to the APIs Results Credit activity is successfully recorded and triggers credit score recalculation Pass / Fail Pass Table 5.3 Credit Score Calculation Test Case Test Case Generate user credit score 42 Description A user credit activity automatically triggers a credit score calculation Results The credit score is generated and persisted to the datastore Pass / Fail Pass Table 5.4 Mobile Authentication Test Case Test Case User mobile authentication Description A user who had downloaded the application is able to log in Results Authentication is successful and user is able to log in Pass / Fail Pass Table 5.5 Manage Lenders Test Case Test Case Manage Lenders Description A system administrator logs into the administration panel, updates a lender’s account status Results The updates are reflected in the database and are applied immediately Pass / Fail Pass 5.3.1.2 Acceptance Testing This is formal testing to determine whether or not the system satisfies it’s acceptance criteria and to enable the customer to determine whether or not to accept the system and is performed by the customer. Figure 5.6 shows the responses from users on the ease of authentication and access to their data. 43 Figure 5.11 User Authentication Figure 5.7 shows responses from users on their satisfaction in the data displayed to them on their dashboards. Overall, users were satisfied with the application with 10% of respondents wanting a summary of how much they could borrow from the potential lenders. Figure 5.12 User Dashboard Satisfaction 100% 0% Easy Difficult 90% 10% Satisfied Dissatisfied 44 Figure 5.8 shows responses from microlending companies on the completeness of the APIs provided to them. This was meant to understand what functionalities they thought were not provided by the existing system. Figure 5.13 Lender API completeness 5.4 Summary The system requirements formulated in the requirements gathering and analysis stage provided fundamental information that was used to develop the system while the system design provided a basis for how the system was implemented. The research questions and objectives played a huge role in ensuring that the system was implemented to achieve the user requirements. System testing was conducted to ensure the functionalities provided by the system function as required and all requirements met. 80% 20% Complete Partially complete 45 Chapter 6: Conclusion, Recommendations and Future Work 6.1 Introduction The research was done with the purpose of coming up with a mobile based system to enhance credit scoring in the microlending industry. In this chapter, the researcher seeks to validate that the objectives were met and how the application developed maps against existing credit scoring and aggregation techniques. 6.2 Findings and Achievements During the study, interviews were conducted to validate the usability of the developed system. This is because the system requires the microlending companies to submit credit information to a central system that uses it to perform credit scoring on users. Users also get to have a mobile application that reports any submitted credit activity and information that helps them borrow and repay in good time to retain a high credit score. 6.3 Recommendation The research contains objectives that guided the entire research process. The first objective in section 1.4 is to investigate factors considered when determining a user’s credit score. In section 2.3, the researcher analyses different techniques used in the industry to determine user credit scores. The shortcomings of these techniques are what prompted the research for a more data driven technique for credit scoring and the development of the credit scoring prototype. The second objective was to analyse the different factors considered when determining a user’s credit score. Section 2.4 looks at the 2 main factors taken into consideration when determining a user’s credit score. This helps in the application design and led into the third objective which was to develop and test the credit scoring prototype. The final objective was to validate that the developed prototype generates reliable credit scores. After testing the prototype against numerous test cases, it was concluded that the core system functionality works as required. Section 5.3.1.1 describes the test cases the system was ran against. 46 6.4 Future Work This study focused on credit scoring based on a user’s credit history and ongoing credit activity. However, more possibilities can be explored to ensure that the credit score generated is as a result of both credit activity and the day to day lifestyle of a user. Below are some of the things that can be looked into; i.) Since users have access to the platform via a mobile application, it is possible to tap into the user behavior to further enhance the credit score. ii.) Besides showing potential lenders to the user, add functionality to display approximately how much the user can borrow from the lender iii.) Add functionality for users to borrow from lender via the mobile application. This is not only a good experience for the user but the system will have direct transparency into the borrowing activities of the user and provide an even more reliable credit score. 6.5 Conclusion The application received good feedback from the microlending companies involved in the initial pilot. All contacted companies were impressed by the amount of transparency the system provided. Users involved in beta-testing the mobile application were also impressed by the information it provides and the future capabilities it makes possible. The system met the user requirements it was designed for. 47 References Atkins, J. (2010). A brief history of lending. Retrieved from https://www.selflender.com/blog/online-lending-history.html Annabelle, A. (2018). The Primary Benefits of Mobile Lending. Retrieved from https://www.become.co/blog/the-primary-benefits-of-digital-lending/ Bell, D. (2003). An Introduction to the Unified Modeling Language. Retrieved from https://developer.ibm.com/articles/an-introduction-to-uml/ Bhat, A. (2019). Exploratory Research: Definition, Methods, Types and Examples. Retrieved from https://www.questionpro.com/blog/exploratory-research/ Chen J. (2019). Neural Networks. Retrieved from https://www.investopedia.com/terms/n/neuralnetwork.asp CBA (2013). How M-Shwari works. Retrieved from http://cbagroup.com/m-shwari/how-m-shwari-works/ Ericsson, M. (2004). Activity Diagrams: What they are and how they are used. Retrieved from https://www.ibm.com/developerworks/rational/library/2802.html Gangreddiwar, A. (2015). 8 Risks in the Banking Industry Faced by Every Bank. Retrieved from https://gomedici.com/8-risks-in-the-banking-industry-faced-by-every-bank/ Guguyu, O. (2019). No CRB listing for defaulters before 6 months. Retrieved from https://www.standardmedia.co.ke/business/article/2001332615/no-crb-listing-for-loan- defaulters-before-6-months Harzog, B. (2018). Reasons You need a Credit Score. Retrieved from https://creditcards.usnews.com/articles/5-reasons-you-need-a-credit-score Hellem, D. (2017). What is Agile Development? Retrieved from https://docs.microsoft.com/en-us/azure/devops/learn/agile/what-is-agile-development Irby, L. (2018). FICO & FAKO Credit Scores. Retrieved from https://www.thebalance.com/fico-and-fako-credit-scores-960497 Irby, L. (2019). How Borrowing a Loan Impacts Your Credit Score. Retrieved from https://www.thebalance.com/loans-and-credit-score-960031 Kaffenberger, M. & Chege, P. (2016). Digital Credit in Kenya. Time for Celebration of Concern. Retrieved from http://www.cgap.org/blog/digital-credit-kenya-time- celebration-or-concern Kagan, J. (2019). Credit & Debt: Building Credit. Retrieved from https://www.investopedia.com/terms/c/credit_score.asp 48 Kagan, J. (2019). Personal Finance: Credit & Debt. Retrieved from https://www.investopedia.com/terms/c/credit-history.asp Kagan, J. (2019). Judgmental Credit Analysis. Retrieved from https://www.investopedia.com/terms/j/judgemental-credit-analysis.asp Kenton, W. (2019). Business Risk. Retrieved from https://www.investopedia.com/terms/b/businessrisk.asp Kenton, W. (2019). Credit Scoring. Retrieved from https://www.investopedia.com/terms/c/credit_scoring.asp Kenton, W. (2019). Reputational Risk. Retrieved from https://www.investopedia.com/terms/r/reputational-risk.asp Kumar, D. (2019). Overview of System Analysis and Design. Retrieved from http://www.ddegjust.ac.in/studymaterial/pgdca/ms-04.pdf Kwach, J. (2019). Most populated counties in Kenya according to 2019 census. Retrieved from https://www.tuko.co.ke/262119-lists-counties-kenya-by-population-size-wealth- performance.html Labarre, O. (2019). Credit Risk. Retrieved from https://www.investopedia.com/terms/c/creditrisk.asp Medhora, N. (2019). How Does a Personal Loan Affect Your Credit Score. Retrieved from https://www.nerdwallet.com/blog/loans/personal-loan-affect-credit-score/ Mullin, K. (2016). Identifying Lender Risks – Identifying and Mitigating Lending Risks in Lender Finance. Retrieved from https://www.hitachibusinessfinance.com/lender- finance/identifying-lender-risks/ Munda, C. (2020). CBK bars digital mobile lenders from CRB listing. Retrieved from https://www.businessdailyafrica.com/news/CBK-bars-digital-mobile-lenders-from- CRB/539546-5524174-5cujeg/index.html Murray, J. (2019). What is Lending and Types of Lenders. Retrieved from https://www.thebalancesmb.com/what-is-lending-what-are-lenders-398319 myFICO (2018). What is a credit score. Retrieved from https://www.myfico.com/credit- education/credit-scores/ myFICO (2018). What’s in my FICO score. Retrieved from https://www.myfico.com/credit- education/whats-in-your-credit-score/ Owuor, V. O. (2019). Mobile-based lending is huge in Kenya: but there is a downside too. Retrieved from http://theconversation.com/mobile-based-lending-is-huge-in-kenya-but- theres-a-downside-too-124195 49 Owino, J. (2019). Mobile Lending Firms Disburse Sh112bn to Kenyans in 4 months. Retrieved from https://www.capitalfm.co.ke/business/2019/12/mobile-lending-firms-disbursed- sh112bn-to-kenyans-in-4-months/ Pettit, S. (2020). The Different Types of Software Testing. Retrieved from https://www.atlassian.com/continuous-delivery/software-testing/types-of-software- testing Powell-Morse, A. (2017). Object-Oriented Analysis and Design. Retrieved from https://airbrake.io/blog/design-patterns/object-oriented-analysis-and-design Pritchard, J. (2019). Microlending Definition and Examples. Retrieved from https://www.thebalance.com/microlending-315625 Pritchard, J. (2018). How Credit Scores Work and What They Say About You. Retrieved from https://www.thebalance.com/how-credit-scores-work-315541 Segue Technologies. (2015). 8 Benefits of Agile Software Development. Retrieved from https://www.seguetech.com/8-benefits-of-agile-software-development/ Segal, T. (2019). Operational Risk. Retrieved from https://www.investopedia.com/terms/o/operational_risk.asp Smith, P. (2019). What is alternative lending? Retrieved from https://www.fundingcircle.com/us/resources/alternative-lending/ Sonal, S. & Leah, M. (2019). Loans and Securing Financing. Retrieved from https://gettingthedealthrough.com/area/79/jurisdiction/44/loans-secured-financing- kenya/ Spacey, J. (2016). Functional vs Non-functional Requirements. Retrieved from https://simplicable.com/new/functional-vs-nonfunctional Totolo, E. (2018). Kenya’s digital credit revolution 5 years on. Retrieved from http://fsdkenya.org/blog/kenyas-digital-credit-revolution-5-years-on/ Visual Paradigm. (2020). What is Sequence Diagram? Retrieved from https://www.visual- paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/ 50 Appendices Appendix A: Turnitin Report 1 2