Product Requirements Document

Finance Service Hub

A fintech lead-generation and partner-referral platform — a digital bridge between end-users and authorised financial partners (banks, NBFCs, insurers, brokers and mutual fund houses). FSH captures intent, qualifies it, hands it to the right regulated partner, and tracks the sale through to margin and cashback — without ever storing a PAN, an Aadhaar or a bank account number. This document specifies the public site, the Investor portal, the Partner portal and the Super Admin panel.

Version1.0 · Draft
Prepared forMukesh · FSH, Hyderabad
Prepared byScale Us Technologies
DateSeptember 2026
StatusFor client review
ClassificationConfidential

1Overview & Business Model

1.1 What FSH is

Finance Service Hub is an aggregator. It does not underwrite, lend, advise for a fee, or execute trades. It publishes financial products from authorised partners, captures a qualified lead, and redirects the user to that partner's own regulated journey to complete KYC, payment and issuance. FSH earns on referral margin, and shares part of it back with the customer as cashback.

1.2 Why the model matters technically

Because FSH never completes the financial transaction itself, the platform's regulatory surface stays small. No PAN, Aadhaar, card, CVV, bank account or demat credential is ever collected, transmitted or stored by FSH. The database holds four user fields only — name, mobile, email and tracking IDs — plus the post-sale record a partner or the admin enters. Everything sensitive happens on the partner's domain, under the partner's licence.

Data minimisation is the core design constraint. Every feature in this document is designed so that the sensitive step happens on the partner's side. If a future feature requires FSH to hold regulated data, it needs a separate legal review before it is built — it is not a code change, it is a licensing change.

1.3 Revenue flow

StepWhat happensWhere
1 · IntentUser browses a product window and clicks "Apply Now".FSH
2 · IdentifyLogin/registration gate — mobile + email + OTP. A tracking ID and partner code are stamped on the lead.FSH
3 · HandoverUser is redirected to the partner's page with the tracking ID appended. All KYC and payment happen there.Partner
4 · ConfirmationPartner confirmation email lands in the FSH inbox; a parser extracts policy number, amount and partner and writes a sale row.FSH
5 · Cooling20-day cancellation window runs. Cancelled inside it → margin and cashback both become ₹0.FSH
6 · SettleMargin % applied → partner payout queued. Cashback % applied → coupon email fired to the voucher vendor.FSH

1.4 In scope / out of scope

In scope: public marketing site with live market ticker; dynamic product windows; OTP registration and login with conditional CAPTCHA; Investor portal with calculators, the paid AI goal planner, and a claims/rewards window; Partner portal scoped by partner code with margin and payout visibility; Super Admin with no-code product and partner management, lead and traffic analytics, margin and cashback controls, and audit logs; email-to-sheet automation; WhatsApp AI bot; a paid training module; and the security programme in Section 19.

Out of scope: executing any financial transaction; storing KYC documents; holding customer funds; portfolio management or SEBI-registered advice; direct policy issuance; and the partners' own onboarding journeys.

2Roles & Personas

The brief evolved during scoping: an early draft described three logins (Investor, Partner, Admin) and a later addendum streamlined to two (Admin, Investor). This document specifies all three, because the partner-code attribution, margin and payout logic described in the brief cannot function without a partner identity. The Partner role can be switched off from Admin on day one if Mukesh prefers to run partner reporting manually — the data model does not change.

RoleWho they areWhat they can doWhat they can never do
VisitorAnonymous traffic.Browse the site, read products, use the free calculators, watch the ticker.Apply for anything, see any report.
InvestorRegistered end-user. Auto-issued ID in the format ID-YYYY-XXXX, linked to their email.Apply for products, run the AI goal planner (after ₹300), submit claims, track cashback, buy training.See any other user's data, see margins, see partner payouts.
PartnerBank / NBFC / insurer / broker with a unique Partner Code.See only leads and sales carrying their own partner code, edit permitted fields on their own rows, see their pending payout.See other partners' data, change the margin %, change status after admin lock.
Sub-AdminDay-to-day operations staff.Manage leads, verify claims, respond to support, run reports.Change margin or cashback %, add/remove admins, view audit-log deletions.
Super AdminMukesh / platform owner.Everything: products, partners, margins, cashback %, payouts, targeted reporting, MFA and IP rules, audit log.
RBAC is enforced server-side, not in the UI. Every API call re-derives the caller's role and partner code from the signed token and filters the query — hiding a button is never treated as a permission.

3Public Site & Live Market Ticker

3.1 Layout

A single responsive marketing site: utility bar, header with logo and primary navigation, hero with the value proposition and trust badges, the live ticker, the product-window grid, the partner logo wall, and the compliance footer. It must render correctly at 320px, 768px, 1024px and 1440px+.

3.2 The ticker

A horizontally scrolling strip directly under the hero showing live values with the day's change and direction:

Nifty 50Bank NiftyGift NiftyGoldSilverCrude OilDow JonesNasdaqS&P 500

Values are pulled by a server-side scheduled job, cached in Redis with a 30–60 second TTL, and served to the browser from FSH's own endpoint. The browser never calls the market data provider directly — that keeps the API key server-side and stops one popular page from burning the quota. If the feed fails, the ticker shows the last good values with a muted "delayed" marker rather than breaking or showing zeros.

Commercial note — market data is a licensed product. Real-time NSE/BSE quotes require a paid vendor licence and are billed to FSH, not by us. Free and delayed feeds are available and are what we will wire by default; upgrading to a real-time licensed feed is a configuration change plus the vendor's subscription.

3.3 Video & content blocks

A featured "Latest Financial Insights" card links to the YouTube channel, and a content block carries educational articles. Both are admin-editable so Mukesh can swap the featured video without a developer.

4Product Windows & the Login Gate

4.1 Dynamic product windows

Every product on the homepage is a record, not a hard-coded card. Each carries: title, one-line description, long description, icon/image, category, display order, destination partner, redirect URL template, active/hidden flag, and an optional badge ("New", "Offer"). Admin can add, edit, reorder, hide or delete any window and the site updates immediately — no deployment.

The launch catalogue mirrors the approved design: Financial Advisor AI · Recharge & Bill Payments · Insurance Products · Demat, Trading, MF & SIP · Loan Products · Tax Planning & FDs · Tax Filing & Advisory · Bank Assessment & Digital Assets · Vyapar App (Accounting) · Global Investment & Digital Assets · Professional Training · Offers & Rewards. Credit Cards and NPS are added as two further windows.

4.2 The gate

When an un-authenticated visitor clicks "Apply Now" on any window, a modal intercepts the click before navigation. It offers Login or Register, and it remembers the product the user was trying to reach so that after authentication the user is sent straight there — the intent is never lost. Authenticated users skip the modal entirely and go directly to the consent step.

4.3 Consent before handover

Immediately before the redirect, the user sees the partner's name, what will be shared (name, mobile, email only), and an un-ticked communication-consent checkbox. The "Continue to partner" button stays disabled until it is ticked. The consent event — text version, timestamp, IP and user ID — is written to an immutable consent log. This is the record that protects FSH in a DND or mis-selling complaint.

The checkbox must never be pre-ticked, and the consent text must be versioned. If the wording changes, previously captured consents keep pointing at the wording that was actually shown.

5Registration, OTP & Conditional CAPTCHA

5.1 First-time registration

Fields: full name, mobile number, email ID and a CAPTCHA. On submit, a 6-digit OTP is sent to the mobile (and optionally mirrored to email). On successful verification the account is created, a user ID in the format ID-2026-0001 is generated and permanently bound to the email address, and the session begins.

5.2 Returning login

Mobile or email → OTP. No CAPTCHA on a normal login — it is friction the honest user should not see.

5.3 The 3rd-attempt rule

The system counts consecutive failures per identifier and per IP. On the third consecutive failed login or OTP attempt, a CAPTCHA is injected into the form and must be solved on every subsequent attempt until a success resets the counter. Beyond that, exponential backoff applies and a fixed cap (e.g. 10 OTPs per number per hour) prevents SMS-pumping fraud, which is a real and expensive attack on Indian OTP forms.

5.4 Session & auto-logout

A logged-in session terminates after 15 minutes of true inactivity — no click, scroll, keystroke or navigation. A countdown warning appears at 14 minutes with a "Stay signed in" button. Expiry clears the token client-side and invalidates it server-side, so a copied token is useless. Tokens are short-lived JWTs with refresh; refresh is disabled once the inactivity clock fires.

EventTriggerResult
Failed attempt 1–2Wrong OTP or unknown identifierError message, no CAPTCHA
Failed attempt 3Third consecutive failureCAPTCHA appears and is required
Failed attempt 5+Continued failuresBackoff delay, then temporary lock; alert to admin
Inactivity 14:00No user eventWarning modal with countdown
Inactivity 15:00No user eventSession destroyed both sides, redirect to login

6Investor Portal

After login the investor lands on a personal dashboard showing their user ID, their applications and their status, cashback and reward balances with the stage of each, saved calculator runs, purchased training, and support entry points. Navigation follows the order Mukesh specified — Investor Login, Calculators, YouTube, Contact & Support, WhatsApp Support, Partner Login, Admin Login — as a top header on desktop and the identical order in a slide-in drawer on mobile.

My applicationsEvery product applied for, the partner it went to, the date and the current status.
Rewards & cashbackEach eligible purchase with its 20-day countdown, verified amount and coupon dispatch state.
ClaimsSubmit and track a claim for a purchase FSH has not auto-captured.
Goal plansSaved AI planner reports, re-openable and re-printable without paying again.
TrainingPurchased courses with instant access after verified payment.
ProfileName, mobile, email, communication preferences, consent history, delete account.

7Calculators

Three free calculators, available to visitors and investors, presented as one component with a switcher so the layout and the maths engine are shared:

CalculatorInputsOutput
Loan / EMIPrincipal, annual rate, tenure in monthsMonthly EMI, total interest, total payable, amortisation summary
Mutual Fund / SIPMonthly SIP or lump sum, expected return %, yearsInvested, estimated returns, maturity corpus, year-by-year growth chart
RD / FDDeposit amount, rate, tenure, compounding frequencyMaturity value and interest earned

Every calculator ends with a contextual call to action into a matching product window — that is what turns a calculator from a utility into a lead source. Results can be saved to the investor's dashboard when logged in.

8AI Financial Goal & Career Planning Calculator

The platform's paid, differentiated feature. A parent enters their own age, their child's name and age, and selects a target career; the engine projects the cost of that career at the time the child will actually reach it, then works backwards to what must be invested today.

8.1 Inputs

Parent's current ageChild's nameChild's current ageCareer goalCurrent savings (optional)Risk appetite (optional)

Career goals ship with a maintained cost benchmark table — Commercial Pilot, Doctor (MBBS + PG), Engineer (IIT/NIT/private), IAS & Civil Services, Global MBA, Law, Chartered Accountancy, Design, Sports — each with a present-day all-in cost range (tuition, living, coaching, exams) and a typical start age. Admin can edit every benchmark without a developer, which matters because these numbers move every year.

8.2 The maths

Future cost is compounded at a configurable education inflation rate — 8–9% default — over the years until the child reaches the course start age. The required monthly SIP is then solved from the future-value-of-annuity formula at a configurable expected return. The report shows the assumptions on the face of it, because a projection that hides its assumptions is not advice, it is a guess.

Compliance framing. The output is presented as an illustration, not investment advice, with a visible disclaimer, the assumption set, and a note that returns are not guaranteed. FSH is not a SEBI-registered investment adviser and the copy must never imply otherwise.

8.3 The ₹300 payment gate

The user completes the form and sees a teaser — the goal, the years remaining and a blurred corpus figure. Unlocking the full report costs ₹300.

  • User clicks Unlock → order created server-side with the amount fixed on the server, never taken from the browser.
  • Razorpay checkout opens. Card, UPI, netbanking and wallets. No card data touches FSH.
  • Payment completes → Razorpay fires a server-to-server webhook; FSH verifies the HMAC signature against its secret.
  • Only on a verified webhook does FSH write a paid-access token against that report ID and unlock it.
  • Transaction ID is stored and checked for uniqueness so a replayed webhook cannot unlock a second report.
  • The report itself is generated server-side and delivered as rendered output. There is no client-side flag that can be flipped in DevTools to reveal a paid report, because the paid content is never sent to an unpaid browser.

    8.4 Output

    Total corpus required at the target date; the shortfall against current savings; the monthly SIP needed at three return scenarios; a suggested split across mutual funds/SIP, a child plan or endowment, and NPS or long-term pension where the parent's own retirement overlaps; a year-by-year accumulation table; and a clean printable/downloadable PDF summary. Each recommended vehicle links to a matching FSH product window — which is how a ₹300 report becomes a ₹30,000 commission.

    9Claims, Rewards & Cashback Window

    Not every sale is captured automatically — a customer may buy through a partner link that does not send a parseable confirmation. The claims window lets the investor self-report a purchase and lets the admin verify it before any money is committed.

    FieldTypeNotes
    Product categoryDropdownLoans · Insurance · Investments · Credit Cards · Demat · NPS · Training
    Sub-categoryDependent dropdownLoan → Home / Personal / Car / Business / Education / Gold. Insurance → Health / Life / Motor / Travel / Home. Populated from the category.
    Policy / account numberTextReference only. Not a bank account number — validation rejects anything that looks like one.
    Total amountNumberLoan sanctioned amount or policy value.
    Policy statusDropdownActive or Cancelled.
    Purchase dateDateStarts the 20-day clock.
    ProofFile (optional)Policy PDF or screenshot. Stored encrypted, purged after verification.
    Submit ClaimActionWrites to the admin review queue and notifies the investor by email.

    Claim lifecycle: Submitted → Under review → Verified → In cooling period → Eligible → Coupon sent, or Rejected with a reason the investor can see and respond to.

    1020-Day Cooling Period & Auto-Close Logic

    The single most important rule in the platform, because it protects FSH from paying out on business that later reverses. It runs identically for partner margin and for customer cashback.

  • Every sale row records an exact purchase date and time.
  • A scheduled job evaluates open rows daily and computes days elapsed.
  • If the status becomes Cancelled at any point inside 20 days: status → Closed/Cancelled, margin amount → ₹0, cashback → ₹0, the row is flagged and excluded from the partner's payable total and the customer's reward balance.
  • If 20 days pass with the status still Active: status → Verified / Eligible, margin and cashback are computed and locked, and the coupon workflow in Section 11 fires.
  • A cancellation notified after day 20 does not claw back automatically — it raises an admin exception for a manual decision, because by then the coupon may already be with the vendor.
  • Timezone and boundary handling. The clock runs in IST and "20 days" means 20 × 24 hours from the recorded purchase timestamp, not 20 calendar dates. Every state change is written to an audit trail with actor, timestamp and previous value — this is the record that settles a partner dispute.

    11Cashback & Automated Vendor Coupon System

    11.1 Admin-controlled rules

    Cashback is never hard-coded. The admin sets, per product or per category: the cashback percentage (2%, 3%, 5% or any custom value), a minimum purchase threshold (e.g. only products worth ₹2,000+), an optional cap per transaction, and an effective-from date so a rule change never silently rewrites past transactions.

    Cashback amount = eligible purchase value × cashback %, capped at the configured maximum, computed only after the 20-day lock-in clears.

    11.2 The vendor coupon trigger

    The moment a row turns Eligible, an automated workflow generates a verified reward summary — customer name and masked contact, product, purchase date, transaction value, calculated cashback and a unique coupon reference — and emails it to the third-party voucher vendor. The email is queued, retried on failure, and logged with its message ID so dispatch can be proven.

    11.3 Visibility

    The same state machine is shown to all three audiences, in their own language:

    StageInvestor seesAdmin sees
    Pending"Cooling period — 12 days to go"Row with countdown and cancel-risk flag
    Verified"Eligible — ₹640 cashback confirmed"Amount locked, dispatch queued
    Email sent"Coupon issued — check your email"Vendor, message ID, timestamp
    Cancelled"Policy cancelled — not eligible"₹0, excluded from payables, reason logged

    12Partner Portal, Margins & Payouts

    12.1 Partner login

    Each partner receives a unique Partner Code and credentials. Every query the partner portal makes is filtered server-side by that code — a partner cannot see, guess or enumerate another partner's rows even by editing an ID in a URL.

    12.2 Partner dashboard fields

    Partner CodePartner NameProduct NameCompany NamePolicy NumberTotal AmountStatusMargin %Margin AmountPayout state

    Partners have limited edit rights: they may correct a policy number or update a status on their own rows until the row is locked by the admin at payout time. Every edit is versioned and attributed — the previous value is never destroyed.

    12.3 Margin calculation

    The admin sets a margin percentage per product, per partner, or per product-partner pair. The system computes margin amount = total amount × margin % automatically the moment a row is created or its value is edited, and recomputes on any change. Cancelled-inside-20-days rows compute to ₹0 and drop out of the payable total.

    The payout summary shows, per partner: total eligible sales, gross margin, deductions from cancelled rows, amount already paid, and net payable now — with an export for the accountant.

    13Super Admin Panel

    Reached at a custom, non-obvious URL path, protected by MFA and IP allow-listing, and never linked from the public site.

    Product managementAdd, edit, reorder, hide or delete any product window. Changes go live immediately, no deployment.
    Partner managementAdd, edit or remove partners with logo upload. The footer logo wall and partner dropdowns update automatically.
    Lead & traffic dashboardVisitors, unique users, product clicks, leads captured, redirects to each partner, conversion rate, source attribution.
    Sales & margin masterAll partners consolidated. Edit product, company, amount and margin %; margin recalculates live.
    Payout summaryEligible payouts pending per partner, with the cancelled-row deductions shown, not hidden.
    Cashback controlPercentage, minimum threshold, cap and effective date per product or category.
    Claims queueVerify or reject investor claims with a reason; approvals feed the cooling-period engine.
    Training productsCreate courses, set price, upload content, see who purchased and when access was granted.
    Targeted reportingSelect specific user or partner email IDs and route enhanced reports and updates only to them.
    Content & tickerFeatured video, articles, ticker symbol list, disclaimer text, consent wording and its version.
    Users & rolesCreate sub-admins with scoped permissions; suspend or delete users; handle deletion requests.
    Audit logEvery admin action — who, what, before, after, when, from which IP. Append-only.

    14Email Automation & Sheets Synchronisation

    When a partner confirms a sale, the confirmation email arrives in a dedicated FSH inbox. A parser — Make.com, a Google Apps Script, or a native Java IMAP worker — extracts customer name, product, company, policy number, amount and date, and appends a row to the master store.

    Recommendation: the database is the master, the sheet is a mirror. Google Sheets is excellent for Mukesh to eyeball and for the accountant to export, but it is not a safe system of record for money — it has no row locking, no referential integrity and no audit trail. We write to the database first, then push a one-way sync to the sheet. Both dashboards read from the database, so a sheet edit can never corrupt a payout.

    Unparseable emails go to an admin exception queue rather than being dropped, so no sale is ever lost silently. Each parsed row is deduplicated on policy number so a forwarded or resent confirmation cannot create a double payout.

    15AI WhatsApp Bot

    Built on the WhatsApp Business Platform (Cloud API) with a verified business number and Meta-approved message templates.

  • Greeting & discovery — an inbound "Hi" triggers a greeting and an interactive list of product categories; selections deep-link into the matching FSH product window with a tracking ID attached.
  • Educational Q&A — an LLM answers "why do I need term insurance", "what is an ELSS", "how does a cooling period work", constrained to a curated knowledge base and a strict system prompt so it never fabricates a return figure or gives specific investment advice.
  • Policy expiry alerts — for policies FSH knows about, a scheduled job sends template reminders at 30, 15 and 3 days before expiry with a one-tap renew link.
  • Escalation — anything the bot cannot resolve is handed to a human with the full conversation attached.
  • Platform constraints worth knowing before we build. Meta charges per conversation and only approved templates can be sent outside a 24-hour service window, so proactive expiry alerts are a paid, template-gated flow. LLM inference is also metered. Both are billed to FSH by the provider — we integrate them, we do not resell them.

    16Training Products & Paid Courses

    A dedicated training section listing professional finance, investment, trading and business-skills courses. Each course carries its own price — ₹300 or course-specific — its own Razorpay order, and the identical webhook-verified access model as the AI planner: no verified server-side payment, no content. Content is served through expiring signed URLs so a link copied out of the browser dies quickly, and access is bound to the purchasing account.

    Admin sees enrolments, revenue per course, and completion where the content format supports it.

    17Navigation & Responsive Behaviour

    Navigation order is fixed and identical on both breakpoints, exactly as specified:

  • User Login (Investor Login) — the primary, top-most action.
  • Calculators — expanding to Loan, Mutual Fund and RD/FD.
  • YouTube Channel — link to the channel and the featured video.
  • Contact & Support — form, phone and email.
  • WhatsApp Support — deep link into the bot on the official number.
  • Partner Login — separate entry point.
  • Admin Login — visible only where Mukesh chooses; the real admin path stays unlisted.
  • Desktop (≥1024px): a top header carrying the full order left to right. Tablet and mobile (<1024px): a hamburger opening a slide-in drawer with the same order top to bottom, focus-trapped, dismissible by backdrop tap, swipe or Escape. Touch targets are at least 44×44px and the ticker becomes a swipeable strip.

    18Compliance, Footer & Consent

    The footer is a compliance surface, not decoration. It carries, on every page:

  • Partnership clarification — "Finance Service Hub (FSH) is a technology and lead-generation platform. We offer these services through partnerships with our authorised and regulated partners."
  • Dynamic partner list — names and logos of all active partners, driven by the Admin partner table so it can never drift out of date.
  • Master legal disclaimer — "Financial products/services are provided, approved, issued or executed by the respective authorised/regulated partner, subject to applicable laws and partner terms."
  • Policy links — Privacy Policy, Terms & Conditions, Disclaimer, Grievance Officer contact and a Refund/Cancellation policy for the paid ₹300 report and courses.
  • The un-ticked communication-consent checkbox appears before every form submission that results in data leaving FSH, and the consent version, timestamp and IP are logged permanently.

    19Security Architecture

    19.1 Transport, edge and infrastructure

    TLS everywhereHTTPS enforced with HSTS. TLS 1.2 minimum, 1.3 preferred. No mixed content.
    Cloudflare / WAFManaged rules for OWASP Top 10, bot fight mode, DDoS absorption, origin IP hidden behind the proxy.
    Rate limitingPer IP and per identifier on login, OTP, claim submission, contact and payment endpoints.
    Secrets managementAPI keys, SMS credentials and gateway secrets live in server-side environment configuration — never in front-end code or a repository.

    19.2 Application & data

    Encryption at restDatabase-level encryption; PII columns additionally encrypted at application level.
    Token authShort-lived JWT with rotating refresh, server-side revocation, and OAuth 2.0 where a partner integration requires it.
    Injection defenceParameterised queries throughout — no string-built SQL. Output encoding and a strict CSP against XSS. CSRF tokens on state-changing forms.
    Data minimisationName, mobile, email and tracking IDs only. Schema-level guard: no column exists for PAN, Aadhaar, card or bank account.
    File upload safetyClaim proofs are type- and size-checked, stored outside the web root, served only through signed URLs, purged after verification.
    Payment integrityServer-side order creation, HMAC-verified webhooks, unique transaction IDs, replay rejection. No card data ever reaches FSH.

    19.3 Admin hardening

    Custom hidden admin path; mandatory MFA (TOTP) for every admin and sub-admin; IP allow-listing; separate session policy with a shorter idle timeout; append-only audit logs recording actor, action, before/after values, timestamp and IP; and alerting on privilege changes, margin or cashback edits and bulk exports.

    19.4 Backup & recovery

    Automated encrypted off-site backups — daily incremental, weekly full — with a defined retention window and a documented, tested restore. An untested backup is not a backup; we will run a restore drill before handover and record the RPO and RTO actually achieved.

    19.5 VAPT

    An independent agency performs a Vulnerability Assessment and Penetration Test before public launch. We remediate findings and support the re-test. The audit is commissioned from and billed by the third-party agency; our scope is remediation and re-test support, and launch is gated on a clean report.

    Threat model in one line. The attacks that actually happen to a platform like this are OTP/SMS pumping, payment-bypass attempts on the ₹300 gate, partner-code enumeration in the partner portal, credential stuffing on the admin path, and scraped lead data. Every control above maps to one of those five.

    20Non-Functional Requirements & Status Models

    PerformanceHomepage LCP under 2.5s on 4G. Ticker refresh under 60s. Dashboard queries under 500ms at expected volume.
    Availability99.5% target. Graceful degradation — a dead market feed or SMS gateway must not take the site down.
    ScalabilityStateless application tier behind the proxy; Redis for cache, sessions and rate limits; read replicas when lead volume justifies it.
    AccessibilityWCAG 2.1 AA targets — contrast, keyboard navigation, focus states, labelled form fields.
    SEOServer-rendered marketing pages, semantic markup, sitemap, schema.org FinancialProduct, OG images per product.
    ObservabilityStructured logs, uptime checks, error alerting, and a weekly automated ops digest to the admin.

    20.1 Status models

    Lead: Captured → Consented → Redirected → Converted / Dropped / Rejected.

    Sale: Recorded → In cooling (0–20 days) → Verified / Cancelled → Margin locked → Payout queued → Paid.

    Cashback: Pending → Eligible → Coupon generated → Email sent to vendor → Redeemed / Not eligible.

    Claim: Submitted → Under review → Verified / Rejected → Merged into the sale record.

    Training: Listed → Order created → Payment verified → Access granted → Revoked (refund).

    21Assumptions & Open Questions

    21.1 Assumptions we have built on

  • FSH operates as a lead-generation intermediary and holds whatever registrations that model requires in its own name; Scale Us builds the platform, not the licence.
  • Partner redirect URLs and any tracking-parameter format are supplied by each partner.
  • Market data starts on a free or delayed feed; a licensed real-time feed is a subscription decision.
  • WhatsApp Business, Razorpay, SMS, cloud hosting, Cloudflare, LLM inference and the VAPT audit are third-party services contracted and paid for by FSH at the provider's published rates.
  • Course and article content is supplied by FSH; we build the delivery, not the curriculum.
  • 21.2 Open questions for Mukesh

  • Partner role — in or out at launch? The brief says both. Our recommendation is to build the data model with partner codes regardless, and simply not issue partner logins until you want them.
  • Which partners are contractually live on day one, and do any of them provide a postback/API for conversions rather than an email confirmation? A postback is far more reliable than parsing an inbox.
  • Cashback funding. Cashback is paid out of your referral margin — we need the default percentage and the minimum threshold to configure the engine, and confirmation that the margin covers it.
  • Voucher vendor. Who is the coupon partner, and do they accept an emailed summary or do they have an API?
  • Career cost benchmarks. Who owns and signs off the cost table for each career path? These numbers drive a paid report and need an owner.
  • Refund policy for the ₹300 report and for courses — required before the payment gateway will approve the account.
  • Grievance officer name and contact for the footer, as required for an Indian consumer-facing platform.
  • Real-time vs delayed ticker at launch, and the budget for a licensed feed if real-time is required.
  • Finance Service Hub · Product Requirements Document · v1.0 Draft · September 2026 · Confidential · prepared by Scale Us · © 2026 Scale Us. All rights reserved.
    Working prototype

    Four surfaces. One platform.

    A clickable prototype of the public site (ticker → product → login gate → consent → partner handover), the Investor portal (OTP → calculators → the ₹300 AI goal planner → claims & cashback), the Partner portal (partner-code scoped sales, margin, payouts) and the Super Admin panel.

    Prototype only — figures are illustrative sample data. No live market feed, no real payment, no real partner redirect.
    Delivery timeline

    A 10-week build.

    Six phases across five tracks. Security and the public site first, then the money engine, then the AI and automation layer, then hardening and launch.

    Public site Investor portal Partner portal Admin & backend Security & infra Milestone
    Week 3Staging site livePublic site, ticker, product windows and the OTP login gate, on your domain's staging URL.
    Week 5First demoInvestor portal, calculators and the claims window — you can register and click a product end to end.
    Week 7Money engineMargin, 20-day cooling, cashback and partner payouts computing on real sample data.
    Week 9Feature completeAI planner with live payment, WhatsApp bot, training module, full admin.
    Week 10LaunchVAPT remediation, backup restore drill, handover training and go-live.
    Technology

    Java backend. React front end.

    Server-side Java as specified in the brief, so every sensitive API — SMS gateway, partner integration, payment verification, database access — stays behind the wall and never reaches the browser.

    Client

    React + Next.js

    Server-rendered marketing pages for SEO, a single-page app for the three dashboards, one responsive codebase from 320px up.

    • Next.js (SSR/ISR) + TypeScript
    • Tailwind design system
    • Recharts for portfolio & goal charts
    • PWA-ready, installable
    Backend

    Java · Spring Boot

    The regulated core. Every rule — OTP, RBAC, margin, cooling period, cashback, payment verification — is enforced here, never client-side.

    • Java 21 + Spring Boot 3, Spring Security
    • JWT with rotating refresh + OAuth 2.0
    • MySQL / PostgreSQL, encrypted at rest
    • Redis — cache, sessions, rate limits
    • Quartz schedulers for the 20-day engine
    Edge & integrations

    Cloudflare + partners

    WAF and DDoS at the edge; every third-party call brokered server-side with keys the browser never sees.

    • Cloudflare WAF, bot rules, TLS 1.3
    • Razorpay — orders + HMAC webhooks
    • WhatsApp Business Cloud API
    • Market data feed (cached server-side)
    • SMTP/IMAP parser + Google Sheets sync

    System architecture

    Public siteNext.js SSR
    Investor portalReact SPA
    Partner portalReact SPA
    Super AdminHidden path · MFA
    WhatsAppCloud API
    HTTPS · TLS 1.3
    Cloudflare WAFDDoS · bot rules · rate limiting
    ↓ origin (IP hidden)
    Spring Boot APIauth · RBAC · business rules
    Core services
    Auth & OTPConditional CAPTCHASession & idle lockProduct CMSLead & consentPartner & codesMargin engine20-day cooling jobCashback & couponsAI goal plannerPayments & webhooksTraining accessReportingAudit log
    MySQLencrypted at rest
    Rediscache · sessions · limits
    Object storesigned URLs · course media
    Backupsdaily encrypted off-site
    Outbound adapters
    Razorpayorders · HMAC webhooks
    Partner sitesredirect + tracking ID
    Market dataserver-cached feed
    SMS / EmailOTP · alerts · coupons
    Sheets mirrorone-way sync

    Why this stack

    Java where the money is

    Margin, cooling periods, payouts and payment verification are financial logic. Spring Boot gives strong typing, mature transaction handling and a large hiring pool in Hyderabad.

    Next.js for the shop window

    The marketing site has to rank. Server rendering gives real SEO on every product page while the dashboards stay app-fast.

    Redis for the ticker

    One cached fetch serves every visitor. It keeps the market-data bill flat no matter how much traffic the homepage gets.

    Nothing sensitive on our side

    No PAN, no Aadhaar, no card, no bank account. The schema has no column for them, which is the strongest form of data protection there is.