199 lines
6.6 KiB
Markdown
199 lines
6.6 KiB
Markdown
# Core Idea
|
|
|
|
## One-line thesis
|
|
|
|
A B2B2C fintech platform that turns customer payments into real-time commission balances, gives employees instant access to earned commissions, and gives employers a reliable system of record for commission payouts and performance.
|
|
|
|
## The problem
|
|
|
|
### Employers
|
|
|
|
- Commission calculation is often manual, delayed, and hard to audit.
|
|
- Sales teams ask for informal advances when payroll cycles lag behind real sales activity.
|
|
- Finance teams struggle to forecast commission liability and reconcile payouts.
|
|
- Sales performance data is scattered across spreadsheets, POS tools, CRMs, and payroll systems.
|
|
|
|
### Employees
|
|
|
|
- A sale can happen today, but the commission may not be usable for days or weeks.
|
|
- Early access to money often depends on asking for an informal advance.
|
|
- There is rarely a clear view of what has been earned, what is available, and what is still pending.
|
|
|
|
## The product
|
|
|
|
The product sits between customer payment collection and employer payout.
|
|
|
|
- A customer makes a payment.
|
|
- The platform receives the payment event directly, or receives trusted payment data from a partner.
|
|
- A commission engine applies employer-defined rules.
|
|
- The internal ledger allocates balances between employer and employee.
|
|
- A safe portion of the employee's commission becomes available immediately.
|
|
- The employee can cash out instantly, and later can also spend from a wallet or card.
|
|
- The employer gets the remaining balance on a defined settlement schedule.
|
|
- Both sides get visibility into earnings, payouts, and performance.
|
|
|
|
## Core product layers
|
|
|
|
### Payment collection or orchestration
|
|
|
|
- Accept customer payments directly, or integrate with the employer's processor.
|
|
- Use payment events as the source of truth for commission creation.
|
|
|
|
### Commission rules engine
|
|
|
|
- Support percentage-based, tiered, and custom rules.
|
|
- Lock an auditable calculation for every sale or payment event.
|
|
- Track exceptions, reversals, and dispute states.
|
|
|
|
### Ledger and balances
|
|
|
|
- Maintain an internal double-entry ledger.
|
|
- Track at least three states: `earned`, `available`, `settled`.
|
|
- Keep clear subledgers for employee balances, employer balances, fees, reserves, and adjustments.
|
|
|
|
### Instant access rails
|
|
|
|
- Start with instant or fast bank-transfer cash-out on the relevant local rail.
|
|
- Later add stored balance inside the app.
|
|
- Later add a prepaid or debit card linked to the balance.
|
|
|
|
### Employer analytics
|
|
|
|
- Real-time commission liability.
|
|
- Sales staff performance based on actual money movement.
|
|
- Forecasts for payouts, reserve needs, and commission trends.
|
|
|
|
### Optional later financing layer
|
|
|
|
- Employer-backed advances.
|
|
- True risk-based credit only after the business has reliable repayment and reversal data.
|
|
|
|
## Recommended money flow
|
|
|
|
The safest early structure is partner-led custody.
|
|
|
|
- A regulated bank or licensed financial partner holds funds.
|
|
- The platform owns the application layer, commission logic, ledger, and payout orchestration.
|
|
- Cards, local payout rails, KYC, and regulated money movement are handled through partners.
|
|
|
|
Example flow:
|
|
|
|
```text
|
|
Customer pays 1,000 in local currency
|
|
|
|
|
v
|
|
Partner-held account receives funds
|
|
|
|
|
v
|
|
Commission engine calculates split
|
|
|
|
|
+-- Employee commission: 200
|
|
+-- Employer balance: 800
|
|
+-- Platform fee and reserve logic applied
|
|
|
|
|
v
|
|
Employee sees commission balance in app
|
|
|
|
|
+-- Instant cash-out
|
|
+-- Hold balance
|
|
+-- Later: card spend
|
|
```
|
|
|
|
## Product thesis
|
|
|
|
This should not start as a generic wallet, a payroll platform, or a payday loan app.
|
|
|
|
The strongest wedge is:
|
|
|
|
`real-time commission access tied to actual payment events`
|
|
|
|
That positioning matters because it keeps the first product grounded in employer ROI, worker liquidity, and trusted payment data.
|
|
|
|
## Revenue model
|
|
|
|
The business should start with software and money movement economics, not balance-sheet lending.
|
|
|
|
- Platform or SaaS fee for employers.
|
|
- Take rate or processing fee on payment volume.
|
|
- Payout fee or bundled payout plan.
|
|
- Premium analytics tier.
|
|
- Later: interchange from card spend.
|
|
- Later: float-sharing or treasury economics if allowed by partner structure.
|
|
- Much later: advance fee for employer-backed early access products.
|
|
|
|
## What the company is not
|
|
|
|
- Not a general neobank.
|
|
- Not a full payroll processor.
|
|
- Not a full CRM or sales engagement tool.
|
|
- Not a payday lender.
|
|
|
|
The company is best understood as `commission infrastructure`.
|
|
|
|
## Phased expansion
|
|
|
|
### Phase 1
|
|
|
|
- Payment-linked commission calculation.
|
|
- Employer and employee onboarding.
|
|
- Ledger with `earned`, `available`, and `settled` states.
|
|
- Instant payout access.
|
|
- Employer and employee dashboards.
|
|
|
|
### Phase 2
|
|
|
|
- Stored balance and wallet behavior.
|
|
- Better analytics and forecasting.
|
|
- Reserve and holdback controls for refunds and chargebacks.
|
|
- Early employer-backed advance logic for selected customers.
|
|
|
|
### Phase 3
|
|
|
|
- Card issuance.
|
|
- Spend directly from balance.
|
|
- More balance retention and interchange revenue.
|
|
- Deeper employer integrations.
|
|
|
|
### Phase 4
|
|
|
|
- Multi-entity support.
|
|
- Broader partner distribution.
|
|
- Carefully controlled credit products if the data and regulation support them.
|
|
|
|
## Key risks and guardrails
|
|
|
|
### Regulatory boundary
|
|
|
|
- Do not begin by directly holding deposits or acting like an unlicensed financial institution.
|
|
- Use a licensed partner for custody and regulated money movement.
|
|
|
|
### Reversals and chargebacks
|
|
|
|
- Do not make all commissions instantly withdrawable on day one.
|
|
- Use availability rules, reserves, and holdbacks.
|
|
|
|
### Commission disputes
|
|
|
|
- Require explicit employer-approved rules.
|
|
- Preserve a full audit trail for every calculation and adjustment.
|
|
|
|
### Labor and tax treatment
|
|
|
|
- Distinguish `earned access` from `credit`.
|
|
- Map payroll, withholding, and deduction obligations with counsel before product launch.
|
|
|
|
### Partner dependence
|
|
|
|
- Expect early dependence on bank, card, and processor partners.
|
|
- Build the ledger and business logic so the company can swap infrastructure providers later.
|
|
|
|
## Current strategic recommendation
|
|
|
|
- Keep the core ledger, commission logic, and employer workflows geography-agnostic.
|
|
- Choose launch markets based on payment-event traceability, employer pain, partner availability, and local payout rails.
|
|
- Use partner-led custody and compliance.
|
|
- Lead with fast access to earned commissions over the relevant local rail.
|
|
- Treat stored balances and cards as retention tools, not the initial wedge.
|
|
- Treat employer analytics as a second major value driver.
|
|
- Delay true lending until the core ledger and payout engine are reliable.
|