Finvest
digital pitches, real deals
The problem Finvest solves
Access to small-ticket capital is still broken for many micro-entrepreneurs. The two-sided problem is clear:
- Borrowers need quick, practical funding for inventory, equipment, and short-term working capital.
- Investors avoid these deals because risk is hard to observe and cash usage is hard to control.
Traditional options fail in opposite ways:
- Formal lending is slow and document-heavy for small, urgent capital needs.
- Informal lending is fast, but investors have weak visibility once cash leaves their account.
- Even when intent is good, there is often no structured flow to enforce disciplined fund usage.
What people can use FinVest for
- Funding small retail inventory cycles (kirana restock, seasonal goods)
- Small manufacturing or food business working capital
- Service business equipment purchases
- Vendor-tied micro expansion (raw materials, tools, service contracts)
How FinVest makes this safer and easier
- Funds are not handed as unrestricted cash; they are controlled by escrow logic.
- Borrower progress is tied to tranches and proof submissions.
- Payouts go to verified vendors, reducing end-use ambiguity.
- Investor and borrower both get transparent status for deal funding, release, repayment, and risk.
- Recovery actions are progressive (reminders -> pause -> freeze -> default), balancing empathy with enforceability.
In short, FinVest enables capital flow where trust is low by replacing manual trust checks with product rules.
What FinVest Does
FinVest supports the full borrower-investor lifecycle:
- Borrower creates a pitch.
- Investors place bids with deal terms.
- Borrower accepts one offer and a deal is created.
- Investor funds the deal (locked balance).
- Borrower requests tranche releases with evidence.
- Admin/investor approves release.
- Payout executes to verified vendor.
- Repayments are tracked with trust/risk signals.
Key capabilities
- Multi-role platform: Borrower, Investor, Admin
- Escrow-backed state tracking (locked vs used balance)
- Tranche workflow with verification and approvals
- Vendor verification workflow
- Repayment schedule and overdue handling
- Risk engine for trust health (GREEN/YELLOW/RED)
- Optional blockchain audit trail (hash/event logging)
Challenges we ran into
The hardest challenge was consistency across a multi-step, interdependent transaction system.
Challenge 1: Maintaining consistent state across dependent operations
A single user action could trigger multiple updates:
- bid acceptance -> deal creation
- deal funding -> balance update
- tranche approval -> payout request
- payout execution -> tranche status + event logs
Risk: partial completion could leave records mismatched.
How we handled it:
- enforced explicit state transitions
- added guard checks to avoid invalid repeats
- centralized business rules in controllers/services
Challenge 2: Optional integrations should not break core flow
AI services and blockchain logging are useful but should not become single points of failure.
How we handled it:
- optional model endpoints with fallback behavior
- blockchain queue/retry pattern
- core escrow/deal operations continue even if optional systems are unavailable
Challenge 3: Balancing strict enforcement with borrower realism
Overly rigid systems can punish temporary delays.
How we handled it:
- progressive recovery ladder
- pause/freeze/default in stages
- risk score + reason codes to support transparent decisions
Tracks Applied (2)
Google Gemini
Major League Hacking
MongoDB Atlas
Major League Hacking
Technologies used