Methodology, Results, and Discussions

The LendRow project is a peer-to-peer lending platform connecting lenders and borrowers in a secure digital space. It simplifies financial transactions by enabling lenders to offer loans with flexible terms from ₱500.00 to ₱10,000.00. Borrowers benefit from a thorough verification process requiring two valid IDs, ensuring trust and reducing fraud. Once verified, users can access all platform features, including lending and borrowing.

LendRow’s virtual wallet streamlines fund management, allowing cash-ins and cash-outs via GCash and Maya in amounts from ₱20.00 to ₱10,000.00. Admins manually verify cash-ins, while cash-outs incur a small fee to support the platform. Both lenders and borrowers have access to detailed transaction histories, promoting transparency and accountability.

The platform promotes responsible borrowing by restricting new loan applications until current debts are fully repaid. Borrowers manage payments through the system, and lenders track repayment statuses. Once loans are repaid, agreements are updated to reflect closure, confirming the transaction’s completion. With trusted payment systems, strict verification, and transparency, LendRow offers a secure and accessible financial solution.

Requirements Analysis

Figure 4.1 Level 4 data flow diagram explosion

The Level 4 Data Flow Diagram illustrates the workflow within the LendRow platform, highlighting the structured interactions between lenders and borrowers. The process begins with lenders defining their lending terms, including interest rates, repayment periods, and acceptable collateral, which are processed through the wallet system. This stage, labeled "Setting the Lending Terms" (Process 4.1), organizes the lender’s input into accessible options stored in the system. Borrowers then engage with the platform by exploring available lenders or funds through "Inquiring Available Lenders or Funds" (Process 4.2). Acting as the central hub, the wallet system seamlessly connects lenders’ predefined terms with borrower inquiries, fostering an efficient and transparent process that bridges the gap between the two parties.

Figure 4.2 Level 5 data flow diagram explosion

The Level 5 Data Flow Diagram provides a clear and systematic view of the loan application process within the LendRow platform. The journey begins with borrowers submitting their personal information and collateral, all guided by pre-established lending terms. This data is processed in the "Complying the Loan Application" (Process 5.1), where it is reviewed alongside financial details and securely stored in the applications repository. Next, lenders assess the submitted applications in the "Validating Loan Applications" (Process 5.2), carefully evaluating borrower information, collateral, and credit history. Once an application is approved, the system generates a formal lending agreement that clearly defines the loan amount, repayment terms, and other key details, solidifying the transaction and fostering trust between lenders and borrowers.

Figure 4.3 Level 6 data flow diagram explosion

The Level 6 Data Flow Diagram provides a detailed view of the loan disbursement process within the LendRow platform, focusing on the seamless interaction between lenders, borrowers, and the wallet system. The process begins with the lender validating the loan applications (Process 6.1), carefully reviewing borrower details, collateral, and loan terms to ensure compliance. Once approved, the system generates a lending agreement, which is authenticated and signed by both parties during the "Printing the Lending Agreement" stage (Process 6.2). After the agreement is finalized, the lender proceeds to "Releasing the Financial Funds" (Process 6.3), verifying the disbursement before transferring the loan amount to the borrower’s wallet. The borrower then completes the process by "Acknowledging the Financial Fund" (Process 6.4), formally confirming receipt of the loan. This structured and transparent workflow promotes trust, accountability, and secure handling of financial transactions between users.

Functional Requirements

Functionality

F1: The system shall allow users to register by providing their first name, middle name, last name, username, mobile number, and password.

F2: The system shall require users to upload two valid IDs for identity verification before gaining access to the main site.

F3: The system shall restrict unverified users from accessing lending and borrowing features until the admin verifies their identity.

F4: The system shall redirect verified users to their respective pages (Lenders’ Page or Borrowers’ Page) upon successful login.

F5: The system shall allow lenders to define lending terms, including loan amounts (₱500.00 to ₱10,000.00), interest rates (10% for 1–6 months, 5% for 7–12 months), repayment terms, and collateral types (property, cars, or items).

F6: The system shall prevent lenders from offering loans if their wallet balance is insufficient and shall prompt them to cash in first.

F7: The system shall provide cash-in and cash-out functionality, allowing users to cash in amounts ranging from ₱20.00 to ₱10,000.00 through GCash or Maya.

F8: The system shall require admin approval for all cash-in and cash-out requests before updating the user’s wallet balance.

F9: The system shall deduct the loaned amount from the lender’s wallet upon funding a borrower’s loan application.

F10: The system shall allow borrowers to apply for loans by specifying the desired amount and attaching proof of collateral.

F11: The system shall display borrower applications to lenders, including borrower details, collateral information, and credit history (if available).

F12: The system shall enable lenders to approve or reject loan applications.

F13: The system shall generate and store a lending agreement for approved and funded loans, accessible to both lenders and borrowers.

F14: The system shall allow borrowers to track their loan applications by status: pending, approved, or funded.

F15: The system shall prevent borrowers with existing unpaid loans from applying for new loans until their current debt is fully repaid.

F16: The system shall allow borrowers to make monthly payments on approved loans, tracking the payment status as paid or unpaid.

F17: The system shall update the lending agreement to a closure agreement once the borrower has successfully repaid the loan in full.

F18: The system shall maintain transaction history logs for all lending, borrowing, cash-in, and cash-out activities.

F19: The system shall allow admins to monitor and manage user verifications, transaction approvals, and system logs.

F20: The system shall charge a ₱10.00 service fee for each cash-out transaction processed by the admin.

Data

User Data including first name, middle name, last name, username, mobile number, email, profile picture, and password, shall be securely stored in a relational database.

• Format: Text fields (e.g., VARCHAR) for names and contact details, DATETIME for timestamps, and file paths for storing image references.

• Storage: Encrypted within the users table. Passwords will be hashed using a secure algorithm like bcrypt.

• Validation: Input will be validated for completeness, format (e.g., proper email and phone number formats), and uniqueness (e.g., username and email).

• Privacy: Sensitive information, such as passwords, will be encrypted, with access restricted based on user roles.

Wallet Data including user ID, full name, mobile number, and balance, will also be securely stored in a relational database.

• Format: Numeric fields (DECIMAL) for balances and text fields for identifiers and contact details.

• Sources: User actions like cash-in or cash-out, admin approvals, and lending transactions.

• Storage: Stored in the wallet table and linked to user accounts via foreign keys.

• Integrity: Updates to wallet balances will follow strict transactional logic to ensure accuracy and consistency.

Transaction Data such as cash transaction details, including transaction ID, user ID, method, amount, status, payment account details, and receipt, shall be recorded in the database.

• Format: Numeric fields (DECIMAL) for amounts, text fields for methods and account details, and file paths for receipts.

• Sources: User-submitted cash-in and cash-out requests.

• Storage: Stored in the cash_transactions table, linked to user wallets through foreign keys.

• Validation: Admin verification will ensure transaction accuracy and prevent fraud.

• Security: Only authorized users and admins can access payment details and receipts.

Lending and Application Data including lender name, borrower name, loan amount, interest rate, term, collateral type, and status, along with application data (borrower name, collateral proof, and status), will be securely stored.

• Format: Text fields for names and collateral details, numeric fields for financial data, and dates for timestamps.

• Sources: User inputs during lending or application processes.

• Storage: Recorded in the lending_terms and applications tables.

• Validation: Borrower credit history and collateral proof will be verified before loan approval.

• Privacy: Only lenders, borrowers, and admins will have access to detailed loan and application information.

Financial Details for loans, including monthly payment status, due dates, and terms, will be maintained in a structured database.

• Format: Text fields for statuses, dates for payment updates, and numeric fields for amounts.

• Sources: Derived from loan agreements and borrower payments.

• Storage: Stored in the financial_details table, linked to lending agreements and applications.

• Integrity: Payment records will be systematically tracked to prevent duplication or missed updates.

Admin wallet and transactions including virtual and system balances, and transaction details (amount, status, and method), will be securely recorded.

• Format: Numeric fields (DECIMAL) for balances, text fields for methods, and dates for timestamps.

• Sources: Admin operations for approving or denying cash-in and cash-out requests.

• Storage: Stored in the admin_wallet and admin_wallet_transactions tables.

• Validation: All transactions will be logged and fully auditable.

Collateral Data including type and proof of ownership, will be securely stored.

• Format: Text fields for type and file paths for ownership proof documents.

• Sources: Uploaded by users during loan applications.

• Storage: Stored in the applications table, linked to lending terms.

• Security: Only authorized lenders will have access to collateral information.

Login Details such as user ID, device, browser, IP address, user agent, and login time, will be logged for security and session tracking.

• Format: Text fields for identifiers and user agents, and dates for timestamps.

• Sources: Captured during user authentication processes.

• Storage: Stored in the login_details table.

• Privacy: Sensitive data like IP addresses will be encrypted to ensure user security.

Data processing methods including input validations, database integrity checking, and data encryption for system security purposes shall be implemented properly.

• Validation: Input fields will be validated both client-side and server-side, ensuring formats like valid email addresses, phone numbers, and strong passwords. Admins will manually verify IDs and receipts where required.

• Integrity Checks: Database constraints such as foreign keys, unique constraints, and default values will maintain data consistency. Transactions will be used to ensure atomic updates for sensitive operations like balance adjustments.

• Encryption: Sensitive data like passwords will be hashed with bcrypt, and fields such as payment numbers and IP addresses will be encrypted.

Data security and privacy including user access control, user data encryption, audit logging, and regulatory compliance shall strictly be implemented.

• Access Control: Role-based access will restrict sensitive information to authorized personnel. Borrowers and lenders will only see their own data.

• Encryption: Secure transport (e.g., HTTPS) will be enforced, and sensitive fields will be encrypted at rest using algorithms such as AES.

• Audit Logging: All updates to financial and user data will be logged for traceability and accountability.

• Compliance: The system will adhere to data protection regulations such as GDPR and the Data Privacy Act of the Philippines, ensuring legal compliance and user trust.

User Interface

UI1: Intuitive Navigation and Clear Information

Figure 4.4 LendRow’s system navigation

The LendRow platform will feature a user-friendly interface designed to ensure intuitive navigation. Key information, such as registration, lending, and borrowing options, will be prominently displayed to guide users effectively.

UI2: Interactive Registration and Verification

Figure 4.5 LendRow’s registration and verification

The registration page will include clearly labeled forms for first name, middle name, last name, username, mobile number, email, and password. Upload buttons will support drag-and-drop or file selection for ID verification. Tooltips will provide real-time validation feedback, such as “Invalid LastName.” or “Invalid Username.”

UI3: Dashboard for Lenders and Borrowers

Figure 4.6 LendRow’s lender and borrower pages

Users will access tailored dashboards based on their role (lender or borrower) post-verification. The lender dashboard will include options for viewing active loans, pending applications, and transaction histories. Borrower dashboards will display loan applications, payment status, and collateral management tools.

UI4: Wallet and Transactions Interface

Figure 4.7 LendRow’s wallet interface

The wallet section will feature clear balance displays, buttons for cash-in and cash-out requests, and a transaction history list. For mobile accessibility, large, touch-friendly buttons and responsive layouts will ensure ease of use.

UI5: Accessibility and Device Compatibility

Figure 4.8 LendRow’s device compatibility

LendRow will be fully responsive, providing seamless experiences on desktops and smartphones. Accessibility features such as keyboard navigation, screen reader compatibility, and color contrast adjustments will be included to ensure inclusivity.

UI6: Progress Indicators and Feedback

Figure 4.9 LendRow’s progress indicators

Progress indicators will guide users through multi-step processes like registration, loan applications, or cash transactions. Real-time feedback, such as “Pending or Approved,” will keep users informed.

Non-Functional Requirements

Technical Requirements

T1: Response time shall ensure an average response time of less than 5 seconds for all key operations, including page navigation, loan application submissions, and wallet transactions.

T2: Peak load capacity shall be designed to handle a peak load of 500 concurrent users without performance degradation.

T3: Browser compatibility shall be compatible with major web browsers, including Google Chrome, Mozilla Firefox, Microsoft Edge, and Safari. Internet Explorer will not be supported.

T4: Platform compatibility shall be fully operational on desktop and mobile web browsers, but it will not have native support for iOS or Android applications at this stage.

T5: Scalability of the platform shall be hosted on a scalable cloud infrastructure (e.g., AWS, Azure, or GCP, InfinityFree), allowing seamless expansion to support increased data volumes, user accounts, and transactions.

T6: Data throughput shall process a minimum of 100 transactions per second, ensuring smooth financial operations and updates.

T7: Integration with Third-Party APIs shall seamlessly integrate with payment gateway APIs (e.g., Gcash, Maya) for secure cash-in/cash-out transactions. Future integration with identity verification APIs shall also be supported.

T8: Data backup and recovery of the system is automatic with daily backups of all critical data, including user profiles, wallets, and transaction histories, shall be implemented. Recovery time objectives (RTO) shall not exceed 2 hours in case of a failure.

T9: Security measures shall employ HTTPS encryption, ensure secure password hashing with bcrypt, and enforce role-based access control (RBAC) to protect sensitive user and financial data.

T10: Ensure 95% of user requests have a response time under 300ms, even under high traffic, using edge caching, CDNs, and query optimizations.

Security Requirements

S1: Data encryption of all sensitive data, including user information, passwords, and financial records, shall be encrypted both in transit and at rest using industry-standard protocols like AES-256 for storage and TLS 1.3 for transmission.

S2: Strong password policies of the system shall enforce strong password policies, including uppercase, lowercase, numbers, and special characters. Passwords shall be securely hashed using algorithms like bcrypt with a high work factor.

S3: Role-Based Access Control (RBAC) to system functions and sensitive data shall be managed through role-based access control, ensuring users can only access features and data relevant to their role (e.g., admin, borrower, lender).

S4: Intrusion detection and prevention system shall include a robust intrusion detection and prevention system (IDPS) to monitor, detect, and respond to unauthorized access attempts or malicious activities.

S5: Regular security audits and penetration testing shall be conducted at least quarterly to identify vulnerabilities and ensure compliance with security standards.

S6: Secure session management shall implement secure session management by using encrypted cookies, automatic session expiration, and protections against session hijacking.

S7: Access logging and monitoring of all access and system interactions shall be maintained for auditing purposes. Anomalies and suspicious activities shall trigger immediate alerts for investigation.

S8: Protection against common threats shall include defenses against common vulnerabilities, including SQL injection, XSS, CSRF, and brute force attacks.

S9: Backup and disaster recovery shall be maintained, and a disaster recovery plan shall ensure data integrity and availability during disruptions.

Legal Requirements

L1: The website shall comply with the Philippine Data Privacy Act of 2012 (RA 10173) to ensure the protection of personal data.

L2: The website shall comply with the Consumer Act of the Philippines (RA 7394) to safeguard consumer rights and fair trade practices.

L3: The website shall comply with the E-Commerce Act of 2000 (RA 8792) to ensure lawful online transactions and digital agreements.

L4: The website shall comply with all applicable tax laws, including filing and remittance of taxes to the Bureau of Internal Revenue (BIR).

L5: The website shall comply with intellectual property laws (e.g., RA 8293 – Intellectual Property Code of the Philippines) to protect copyrights, trademarks, and other intellectual property rights.

User Requirements

UR1: The platform shall be easy to use and navigate, ensuring accessibility for all users.

UR2: The platform shall provide secure and reliable user registration and login processes.

UR3: The platform shall include clear guidance for lenders and borrowers to complete their respective actions, such as lending, borrowing, and making payments.

UR4: The platform shall provide real-time notifications to users regarding the status of their transactions (e.g., cash-ins, loan approvals, payments).

UR5: The platform shall allow users to view and manage their transaction history, lending agreements, and payment statuses conveniently.

UR6: The platform shall educate users on the terms, conditions, and policies governing lending and borrowing activities to foster transparency.

UR7: The platform shall ensure fast load times and responsive interactions for an optimal user experience.

Development and Testing

Development Methodology

Figure 4.10 Agile Methodology

The development of the Lendrow platform followed the Agile methodology, which allowed for flexibility, iterative development, and continuous feedback. Agile was chosen due to the evolving requirements of the project and the need to implement updates and features incrementally. This approach ensured that the platform could be continuously improved and adapted to meet user needs efficiently.

Development Phases

Requirements Gathering: Requirements were gathered iteratively, focusing on one process at a time. Regular feedback from potential users and stakeholders guided the refinement of the platform's features.

Design: The design phase focused on creating a modular and scalable architecture. User interface designs were improved with each sprint, ensuring enhanced usability and security with every iteration.

Implementation: Development was conducted incrementally, with each sprint delivering a working feature or process. New updates and features were added iteratively, allowing for ongoing improvements and enhancements during the development cycle.

Testing: Testing was an integral part of every sprint, ensuring that each process worked as intended before moving to the next. The testing procedures included:

• Unit Testing to validate individual components.

• Integration Testing to ensure seamless interaction between processes.

• System Testing for end-to-end functionality.

• User Feedback Testing during each sprint to identify and resolve issues.

Deployment: Deployment was done incrementally after successful sprints. Early releases allowed users to provide feedback and ensured a smooth transition to the fully functional platform.

Maintenance: The platform underwent continuous maintenance and updates during and after development. A complete rebuild of the system was undertaken over one and a half months, incorporating enhanced security and design improvements to address user feedback and evolving requirements.

Development Environment

The development of the Lendrow platform utilized a range of tools and technologies, ensuring a streamlined and efficient process. The following components comprised the development environment:

Programming Languages:

• PHP: For server-side scripting and backend development.

• HTML: For structuring the web pages.

• CSS: For styling and enhancing the visual presentation of the platform.

• JavaScript: For interactive and dynamic user interface functionalities.

Development Tools:

• Notepad++: A lightweight and efficient text editor used for coding PHP, HTML, CSS, and JavaScript, offering ease in handling extensive codebases.

• XAMPP: A local development environment incorporating Apache for the web server, MySQL for database management, and PHP for backend processing. This facilitated testing and debugging during development.

Database:

• MySQL: A robust and reliable relational database system used to manage and store platform data, including user information, transactions, and loan agreements.

Cloud Deployment:

• InfinityFree: A free cloud hosting platform was used to deploy the Lendrow platform, making it accessible online for testing and demonstration purposes.

Operating System:

• Windows: The development and deployment processes were conducted on a Windows-based system, providing compatibility with the chosen tools and technologies.

Testing Procedures

To ensure the quality and reliability of the Lendrow platform, the following testing activities were conducted during the development process:

• Unit Testing: Individual components and modules of the system were tested in isolation to verify their functionality. For instance, the loan application module, user registration form, and cash-in/out processes were tested independently to ensure they behaved as expected.

• Integration Testing: The interaction between different components of the system was tested to identify any issues arising from module integration. Examples include validating data flow between the user registration process and the identity verification system, and ensuring seamless interaction between the lender wallet and lending terms.

• System Testing: The entire platform was tested as a unified system to ensure it met the specified requirements. This included verifying that all user roles (lenders, borrowers, and administrators) could perform their respective tasks without errors.

• User Acceptance Testing (UAT): End-users, including potential lenders and borrowers, were involved in testing the platform to validate its usability and functionality. Feedback was collected and incorporated to improve user experience and address any gaps in meeting user expectations.

Test Data:

• Sample Data: Synthetic data was used to simulate various scenarios, such as loan applications, transactions, and user profiles.

• Real-World Data: Realistic test cases, such as actual lending terms and transaction amounts, were employed to evaluate the platform's performance under practical conditions.

Test Metrics:

• Defect Density: Measured the number of defects identified per module to assess code quality.

• Test Pass Rate: Tracked the percentage of test cases that successfully passed, ensuring adequate coverage.

Implementation Plan

Project Schedule

The implementation of the Lendrow platform followed a detailed project schedule, ensuring timely completion of each development phase.

Key Milestones:

Week 1: Requirements gathering and initial design.

Week 2: Development of user registration and identity verification modules.

Week 3: Implementation of the wallet system and cash-in/cash-out functionality.

Week 4: Development of lending and borrowing processes, including collateral management.

Week 5: Integration of modules and initial testing.

Week 6: Deployment on InfinityFree and user acceptance testing (UAT).

Week 7: Final security enhancements and design improvements.

Resource Allocation:

• Project Lead: Overseeing all phases of development and ensuring alignment with objectives.

• Developer: Responsible for coding, testing, and debugging all modules.

• Tester: Conducting system testing and gathering UAT feedback.

Tracking Progress: Regular monitoring was conducted to ensure adherence to the schedule. Any delays or issues were addressed promptly by reassigning resources or adjusting timelines. Weekly status reports were generated to document progress and highlight completed milestones.

Resource Allocation

The successful development and implementation of the Lendrow platform required the following resources:

• Human Resources:

• Project Manager: Oversaw the entire project, ensured tasks were completed on schedule, and managed resources.

• Developer: Handled coding, integration, and debugging of the platform’s features.

• Tester: Conducted testing at all stages, including unit, integration, system, and user acceptance testing.

• Designer (optional): Assisted with enhancing the user interface and improving platform usability.

Hardware Resources:

• Development Machine: A Windows-based computer or laptop (e.g., Lenovo laptop running Windows 11) with an Intel i3 11th Gen processor, sufficient for coding and testing tasks.

• Server (for local testing): XAMPP software running on the development machine.

• Internet Connection: Reliable internet for online deployment and collaboration.

Software Resources:

• Text Editor: Notepad++ for writing and managing PHP, HTML, CSS, and JavaScript code.

• Development Environment: XAMPP for running a local server with Apache and MySQL.

• Cloud Hosting: InfinityFree for deploying the platform online.

• Browser: For testing and verifying the platform’s functionality.

• Security Tools: Software for enhancing and testing the platform’s security measures.

Financial Resources:

• Hosting Costs: InfinityFree (free cloud hosting used).

• Contingency Funds: ₱2,000.00 for additional tools, internet costs, or optional hosting upgrades if required.

Risk Management

Risk Identification

Below are potential risks associated with the development and operation of the PrimeLendrow platform:

Technical Risks:

• Bugs or errors in the system affecting functionality (e.g., loan disbursement, wallet transactions).

• Data breaches or unauthorized access compromising sensitive user information.

• System downtime or server crashes during high traffic periods.

Financial Risks:

• Budget overruns due to underestimated development or maintenance costs.

• Delayed cash flow due to unresolved pending transactions or administrative bottlenecks.

Operational Risks:

• Delays in admin approval for user verification and cash-ins causing dissatisfaction.

• Mismanagement of wallets or discrepancies in balances.

Compliance Risks:

• Non-compliance with financial and data privacy regulations, such as the Philippines' Data Privacy Act.

• Legal challenges from users due to disputes in lending agreements or repayments.

User Risks:

• Lenders or borrowers providing invalid or fraudulent information.

• Borrowers defaulting on loan repayments, affecting lender trust.

Project Management Risks:

• Schedule delays due to unexpected challenges in development or testing phases.

• Team miscommunication or resource shortages impacting delivery timelines.

Risk Assessment

Table 4.1 Likelihood and Impact Matrix

Risk	Likelihood	Impact	Priority
Bugs or errors in the system	High	High	Critical
Data breaches	Medium	High	Critical
Budget overruns	Medium	Medium	High
Admin approval delays	High	Medium	High
Fraudulent user information	Low	High	Medium
Borrower loan defaults	Medium	Medium	High
Compliance issues	Low	High	High
Schedule delays	Medium	Medium	Medium

Risk Mitigation

Technical Risks:

• Implement thorough testing (unit, integration, and system testing) to identify and resolve bugs early.

• Use strong encryption protocols to protect user data and regularly update security measures.

• Employ cloud-based hosting with scalability options to prevent system downtime during high traffic.

Financial Risks:

• Set aside contingency funds for unexpected expenses.

• Automate financial calculations and transaction tracking to minimize errors and delays.

Operational Risks:

• Implement SLAs (Service Level Agreements) for admin response times to user requests.

• Automate wallet balance tracking to prevent manual errors.

Compliance Risks:

• Consult legal and regulatory experts during development to ensure compliance.

• Regularly audit the system for adherence to privacy and financial laws.

User Risks:

• Require multiple levels of verification (e.g., valid IDs, proof of collateral) for borrowers and lenders.

• Create a credit history system for borrowers to assess their reliability.

Project Management Risks:

• Adopt an Agile methodology to allow iterative development and address issues early.

• Conduct regular progress reviews and adjust timelines/resources as needed.

Risk Monitoring

Regular Risk Reviews:

• Schedule bi-weekly risk assessment meetings to evaluate existing and new risks.

• Performance Monitoring:

• Use automated tools to track system performance and detect anomalies in real-time.

User Feedback:

• Collect user feedback on functionality and operational processes to identify potential risks.

Update Mitigation Plans:

• Revise risk mitigation strategies based on new developments or changes in regulatory requirements.

Communication Plan

Communication Channels:

To ensure clear, consistent, and efficient communication throughout the project, the following channels have been used:

Meetings:

• Regular team and stakeholder meetings to discuss progress, address concerns, and align on objectives.

• Formats: Virtual Meeting and in-person (as needed).

Email:

• For sharing detailed updates, meeting minutes, documentation, and important announcements.

• Used for formal communications with stakeholders.

Project Management Software:

• Tool: Trello/Asana/ClickUp (or similar software).

• Purpose: Track tasks, milestones, deadlines, and overall project progress.

Instant Messaging Platforms:

• Tool: Gmail/Messenger.

• Purpose: For quick queries, updates, and day-to-day collaboration among team members.

Documentation Repositories:

• Tool: Google Drive/GitHub.

• Purpose: Centralized storage for all project-related documents, diagrams, code repositories, and resources.

Communication Protocols

To ensure effective and timely communication, the following protocols have been established:

Clear Objectives:

• Every meeting or communication session has a predefined agenda shared in advance.

• Meeting minutes are documented and distributed afterward to ensure alignment.

Response Time:

• Emails and messages must be acknowledged within 24 hours.

• Urgent issues flagged via instant messaging platforms must be addressed within 4 hours.

Stakeholder Engagement:

• Key stakeholders are consulted during milestone reviews and critical decision-making.

• Feedback from stakeholders is documented and incorporated into the project plan.

Change Management Communication:

• Any changes to the scope, timeline, or budget are communicated immediately through email and discussed in a dedicated meeting.

Documentation Standards:

• All important discussions, decisions, and deliverables are documented and stored in the project repository.

• Version control is maintained for documents to avoid confusion.

Capstone Project Deployment Results

The system was deployed from December 18, 2024, to January 18, 2025, involving two (2) lenders and two (2) borrowers from Davao City. Daily monitoring was limited due to other project commitments, and respondents were not always available because of work and personal obligations. Despite these challenges, most participants were approachable. This highlights the platform's real-world potential and the need for flexible project management.

General Objective: Increase the success of debt collection by 50%.

Table 4.2 Payment/Collection Data

Lender	Lend amount	Interest rate	Payment term	Monthly interest	Lend Date	Expected Paid Date	M1	Collection Rate	Status
Rey	PHP 3,000.00	10% Monthly	1 Month	PHP 3,300.00	January 12, 2025	February 12, 2025	PHP 3,300.00	100%	Paid
Marly	PHP 500.00	10% Monthly	1 Month	PHP 550.00	January 04, 2025	February 04, 2025	PHP 550.00	100%	Paid
Lourdes	PHP 2,000.00	10% Monthly	1 Month	PHP 2,200.00	December 30, 2024	January 30, 2024	PHP 2,200.00	100%	Paid

Figure 4.11 Payment Information

Figure 4.12 Collection Information

A related study by Williams (2023) employed a similar approach, tracking payment and collection data to evaluate the effectiveness of debt collection methods among creditors by using collection rates and repayment statuses.

Table 4.2, Figure 4.5, and Figure 4.6 display payment information from the LendRow platform, focusing on three key transactions. For example, one loan of PHP 3,000.00 at a 10% monthly interest rate for a one-month term, issued on January 12, 2025, was repaid in full by February 14, 2025, achieving a 100% collection rate. Similarly, another loan of PHP 500.00 under the same conditions was fully repaid with a 100% collection rate (first data was excluded as it was used for testing), and Figure 4.6 shows a loan of PHP 2,000.00 issued on December 30, 2024, that was repaid in full by January 05, 2025, also achieving a 100% collection rate.

These records indicate that when loans are processed through the platform, the debt collection process is highly effective, although further data are needed to confirm that overall collection methods consistently improve creditor outcomes, as suggested by Williams (2023).

Specific Objective 1: Decrease the incidence of unmanaged debts by 50%

Table 4.3 Credit Data

Latest Payment	Amount	Payment Term	Status
January 12, 2025	₱3,000.00	1 Month	Paid
January 05, 2025	₱2,200.00	1 Month	Paid
January 04, 2025	₱500.00	1 Month	Paid

Figure 4.13 Credit History 1

Figure 4.14 Credit History 2

A related study by Azmi and Indriyani (2024) used a similar method, analyzing credit history data to assess debt management effectiveness. Table 4.3, Figure 4.7, and Figure 4.8 present credit history information from the LendRow platform, highlighting key transactions such as a ₱3,000.00 payment on January 12, 2025, a ₱500.00 payment on January 04, 2025 (with initial testing data excluded), and a ₱2,000.00 payment on January 05, 2025, all for a one-month term and marked as "Paid". These entries show that borrowers met their repayment obligations on time. Unlike the financial record shown in Appendix A, which allows multiple simultaneous debts, LendRow restricts users from taking on new loans until existing debts are fully repaid, thereby limiting borrowers to a single debt at a time enhances overall debt management practices.

While these preliminary findings are promising, further investigation with a larger sample is needed to fully address the broader challenge of poor debt management. The results also highlight the importance of interventions like financial guidance and structured repayment plans, as emphasized by Azmi and Indriyani (2024).

Specific Objective 2: Increase access to financial resources by 50% for individuals with financial needs

Table 4.4 Monthly Performance Data

Month	Total Loan Listings	Total Open Loan	Total Loan Approvals	Loan Approval Rate
January 2025	3	1	2	66.67%
December 2024	1	0	1	100.00%

Figure 4.15 Monthly Performance Overview

A related study by Demirguc-Kunt, Hu, and Klapper (2019) used a similar quantitative approach—tracking loan application data and approval rates to evaluate financial inclusion. Their research demonstrated that digital lending platforms can significantly improve access to financial resources in underserved regions.

Table 4.4 and Figure 4.9 display key lending data from December 2024 and January 2025 (with February excluded due to testing). In December 2024, one loan listing led to one approval, achieving a 100% approval rate and suggesting an effective loan process when a listing is made. In contrast, January 2025 recorded three listings, two approvals, and one open loan, resulting in a 66.67% approval rate, this variation implies that while the platform efficiently processes individual loans, its overall reach may be limited and some applications require additional review or verification.

Overall, these findings suggest that LendRow is making progress in enhancing financial access, although increasing the volume of loan listings could further improve its impact. This conclusion aligns with the emphasis on processing efficiency and expanded application volumes noted by Demirguc-Kunt, Hu, and Klapper (2019).