LOS
Application → decision → e-sign → disbursal
Loan origination with the Credit Engine wired in. An application flows through knockouts and pricing, becomes a priced offer, gets signed, and reaches disbursal — one workflow, one record, every decision explainable.
Origination, end to end.
- 01
Application intake & product selection
Start from a CRM borrower 360 or a fresh application, and pick the product: single-repayment or an EMI personal loan (3, 6, 9, or 12 months). No re-keying what the CRM already holds.
- 02
Credit Engine decision
The application is sent to the Credit Engine inline: eligibility knockouts, then 10 risk grades, each with pricing bands your credit team configures. Rates are set by the lender, not by Gradexa.
- 03
Approval & offer
Present the priced offer — rate, limit, tenor — from the grade band. Counter-offer or decline flows carry the engine's reason codes for the applicant notice.
- 04
E-sign
Generate the sanction letter, KFS, and agreement — the EMI variants carry the repayment-schedule annexure — and capture e-signature. Documents are versioned against the loan record.
- 05
Disbursal
Move to disbursal and hand off cleanly to the LMS. For EMI loans the amortization schedule is generated at disbursal and stored per installment. NACH mandates and payouts are partial: core logic built, not production-ready.
From application to money out.
- 01Product selection: single-repayment or EMI (3–12 months)
- 02Inline Credit Engine decisioning
- 03Priced offer from the grade's lender-configured band
- 04Amortization schedule generated at disbursal (EMI)
- 05Reason codes for adverse-action notices
- 06Docs with EMI schedule annexure, versioned
- 07E-sign capture
- 08Disbursal hand-off to LMS
Verify a borrower in one flow.
PAN, Aadhaar and face checks run as steps inside the LOS journey, not as separate vendor dashboards your ops team has to reconcile. Each provider is an adapter, so you can switch vendors per program without touching the journey.
Adapters today: Surepass for identity checks, enabled on onboarding with your own credentials; until then the journey runs against deterministic stubs. Razorpay mandates and payments are partial: core logic built, not production-ready.
- 01On onboardingPAN verification
Number verified against the vendor record.
- 02On onboardingAadhaar validation
Number validity check through the adapter.
- 03RoadmapAadhaar OTP eKYC
Full OTP-based eKYC pull.
- 04RoadmapDigiLocker document fetch
- 05On onboardingFace match
Selfie matched to the ID photo, with a configurable threshold.
- 06RoadmapLiveness
- 07RoadmapName match
Vendor-returned names compared to the applicant record.
- 08RoadmapCKYC lookup
- 09BuiltResults stored for audit
Each check result and vendor reference sits on the borrower record, and status changes are audit-logged.
Built = implemented and tested in our codebase.Partial = core logic built, not production-ready.On onboarding = adapter built, enabled with your vendor credentials.Roadmap = not built yet.Gradexa is in active development; no production lenders yet.
From sanction to repayment, without leaving the platform.
Verification, agreements and money movement, stage by stage. Vendors are adapters: bring your own contracts and we wire them on onboarding.
| Stage | What it does | Status |
|---|---|---|
| Bank verification | Penny drop on the payout account through the verification adapter. | On onboarding |
| Bank statements | Statement analysis over Account Aggregator rails to fill income and obligations. | Roadmap |
| KFS + agreement | Sanction letter, Key Fact Statement and loan agreement generated from the decision as one document set, each hashed and versioned. | Partial |
| eSign | Aadhaar OTP eSign on the document set through the adapter; the signed copy is stored against the loan, and disbursal is blocked until every document is signed. | Partial |
| Disbursal | Maker-checker approval, then payout over UPI or IMPS through the payout adapter, with the UTR captured on the loan. | Partial |
| Mandates | eNACH / UPI Autopay registration through the mandate adapter; presentation on the due date with retries, then a manual follow-up flag. | Partial |
| Collections | Payment links for failed presentations and vendor webhooks that reconcile into the ledger. | Roadmap |
Built = implemented and tested in our codebase.Partial = core logic built, not production-ready.On onboarding = adapter built, enabled with your vendor credentials.Roadmap = not built yet.Gradexa is in active development; no production lenders yet.
Where a human looks at the file.
The engine decides; people review the referrals, own the exceptions, and control the money. The desk is being built up in that order.
- 01BuiltWork queue by status
Applications grouped as pending review, referred, approved and declined, newest first, with the engine grade on each row.
- 02RoadmapAssignment to an officer
Files claimed by or routed to a named underwriter.
- 03RoadmapDecision ticket beside the file
Fired rules and score contributions rendered next to the application. The engine response is stored on every application today; the review view is not built yet.
- 04RoadmapKYC review desk
Manual review of name mismatches, low face-match scores and unclear documents, with approve, reject and re-request actions and the reviewer and time logged.
- 05BuiltMaker-checker on disbursal
Money cannot move on one login. Maker and checker roles are set per action and the database refuses a checker who is also the maker.
- 06RoadmapMaker-checker on sanction, with amount limits
Two-person control on the credit approval itself, and approval limits that scale with amount and role.
Built = implemented and tested in our codebase.Partial = core logic built, not production-ready.On onboarding = adapter built, enabled with your vendor credentials.Roadmap = not built yet.Gradexa is in active development; no production lenders yet.
See it decide on a real bureau report.
Request a demo and we'll walk you through the Credit Engine and the Suite on your scenarios. Honest about what's built today, what's partial, and what's on the roadmap.