0→1 Product Fintech · Stock Trading Risk-Free Simulation Biniyog.com.bd · 2023

Paper Trading
Risk-Free Simulation for Retail Investors

How I built Biniyog's paper trading feature from zero - giving thousands of retail investors a consequence-free environment to learn stock trading with real market data, before ever risking a single taka.

↑Users
New registered traders via paper trading onboarding
↑Activation
Free-to-real-account conversion from paper traders
2modes
Virtual Simulation + Virtual Portfolio - distinct use cases
0→1
Full feature built from scratch - no prior simulation infrastructure
01 — Background

Bangladesh's retail investors wanted to trade - but fear of loss kept most of them out.

Biniyog.com.bd is Bangladesh's digital stock brokerage platform - built to democratise access to the Dhaka Stock Exchange for retail investors across the country. By 2023, the platform had a growing user base of registered traders managing real portfolios. But the data told a frustrating story at the top of the funnel: a significant share of registered users never executed a single trade.

Interviews and support conversations kept surfacing the same theme. Users understood the platform. They were interested in trading. But they were afraid to start - afraid of making a costly mistake, afraid of misreading the market, afraid of losing money before they felt ready. The gap between "registered" and "active trader" was a confidence gap, not a capability gap.

Other platforms in mature markets had solved this decades ago with paper trading - a simulated environment where users practice with real market data but no real money on the line. Biniyog had no equivalent. Every new user's first trade was a live trade, with real capital at risk. For a retail investor in Bangladesh with limited disposable savings, that's a high bar. I proposed building paper trading as a first-class product feature, not a secondary tool.

The opportunity framing: If we can give users a safe environment to build confidence before committing real money, we lower the barrier to activation - and every activated trader is a long-term revenue-generating user for Biniyog. Paper trading wasn't a nice-to-have for learning; it was an activation and retention lever.

02 — Problem

Three distinct barriers, each requiring a different product response.

When I dug into why users weren't activating, I found three separate failure modes. Addressing only one would leave the other two intact and conversion would barely move.

01
Financial anxiety blocked the first trade
For many Biniyog users, stock trading represented a significant financial decision - not a casual experiment. The stakes of a first wrong move felt disproportionately high. What they needed was a consequence-free environment where mistakes cost nothing. Reading about trading mechanics is not the same as experiencing them. Users needed to feel the rhythm of placing an order, watching it execute, and tracking their portfolio - without the downside of losing real money while they learned.
02
No way to validate a strategy before going live
More experienced users - those who had done their research and developed a trading thesis - had no way to test their strategy before committing capital. The only test environment was the real market. This was particularly acute for users who had specific strategies in mind: "I think I should buy sector X when Y happens" - but had no mechanism to run that hypothesis against real market data without risk. A paper trading environment would serve these users as a strategy validation layer, not just a beginner's tool.
03
Portfolio managers needed a manual import tool, not just a simulation
A third group had an entirely different problem. Some users were managing existing stock portfolios held through physical BO accounts at other brokerages - but wanted to use Biniyog's portfolio management and analytics tools. They didn't need a simulation; they needed a way to manually import their existing portfolio positions into Biniyog to track and analyse them without routing actual trades through the platform. This was an underserved use case that a "virtual portfolio" concept could address alongside the simulation feature.
03 — Users

Three distinct users - one feature surface, two product modes.

The three barrier types mapped to three user profiles, each with genuinely different needs from a simulation environment. Getting this segmentation right was what led me to build two distinct account modes rather than one.

AB
The Anxious Beginner
Registered but never traded
Understands the platform, wants to trade, but is paralysed by fear of making a costly first mistake. Needs a forgiving environment that mimics real trading exactly - real market prices, real order types, real portfolio tracking - so that confidence built in the simulation transfers directly to live trading. For this user, the simulation must feel real without being real.
ST
The Strategy Tester
Researched, thesis-driven, but cautious
Has done their homework and has a trading strategy they want to validate. May already have some trading experience but wants to test a specific approach - sector rotation, timing signals, a set of entry rules - against actual market data before committing capital. For this user, the simulation is a laboratory: they need accurate price execution, realistic order matching, and performance tracking over time.
PM
The Portfolio Manager
Existing trader using another brokerage
Already actively trading through a physical BO account but wants Biniyog's analytics and portfolio management tools. Doesn't need simulation - needs a way to mirror their real portfolio on Biniyog for tracking and analysis. For this user, manual data entry (trading code, quantity, average cost) is the core workflow, not simulated order placement. This user would actively disengage from a simulation-only solution.

The key insight from this segmentation: Personas 1 and 2 needed a simulation account with virtual funds, real market execution logic, and order lifecycle tracking. Persona 3 needed a manual portfolio import tool with no simulation mechanics at all. Trying to serve all three with a single account type would have produced a product that served none of them well. Two modes was the right architectural decision.

04 — My Approach

Four strategic decisions before writing a single requirement.

01
Build two separate account types, not one flexible account
The temptation was to build a single "virtual account" with configuration options. I rejected this. A simulation account and a portfolio import account have fundamentally different data models, different user flows, and different trust contracts with the user. Simulation needs virtual funds, live order matching, and an automated reset capability. Portfolio import needs manual data entry, custom trade dates, and no fund mechanics at all. Merging them would produce a confusing hybrid. I specified them as two distinct account types with separate creation flows, separate capabilities, and separate UX - even though they share a portfolio interface.
02
Make the simulation maximally realistic, not simplified
Some simulation products use simplified mechanics - rounded prices, instant execution, no commission - to make the experience more approachable. I went the opposite direction. The simulation had to mirror real Biniyog trading as closely as possible: real DSE market prices, commission deducted on each trade, order matching logic tied to actual high/low price ranges, circuit breaker constraints, and settlement timing that mirrors real T+2/T+3 cycles. The reason: confidence built in a simplified simulation doesn't transfer. If a user finds the real platform behaves differently from the simulator they trained on, the confidence benefit is lost.
03
Seed simulation accounts with virtual capital, not zero-balance onboarding
A new simulation account with a zero balance would force users to immediately navigate the deposit flow - adding friction at exactly the moment they should be experiencing the product's value. I specified that every new Virtual Simulation account is automatically funded with a meaningful virtual balance on creation. This meant users could place their first trade within minutes of creating an account, with no administrative steps in between. The seed amount was sized to allow realistic portfolio construction - enough to practice diversification, not just single-stock positions.
04
Design the reset function as a feature, not an admin escape hatch
A simulation that can't be reset has a limited useful life. Once a user has made a few irreversible mistakes, the account state becomes a barrier to continued learning rather than an asset. I specified a full account reset capability - returning the account to its initial funded state, clearing all positions and history - as a first-class user-facing feature. This transforms the simulation from a single-use learning tool into a reusable practice environment. Users can reset after completing a learning goal, before starting a new strategy test, or simply when they want a clean slate. The reset also required a clear disclosure to the user about what it does, which I wrote into the spec.
05 — Product Design

Two account types, one seamless experience inside the existing platform.

The core design constraint was integration, not isolation. Paper trading had to live inside the existing Biniyog platform - same portfolio interface, same buy/sell flow, same fund management screen - not as a separate app or mode. This meant designing virtual accounts as first-class portfolio accounts that happen to have virtual capital, not as a side experience bolted onto the real platform.

The user journey from beginner to active trader

Paper trading was designed not just as an isolated feature but as a structured onboarding pathway - a progressive journey that ends with the user ready and confident to open a real BO account.

📖
Stage 1
Learn the basics via paper trading
📊
Stage 2
Analyse with screeners and market tools
💼
Stage 3
Open a real BO account on Biniyog
📈
Stage 4
Trade consistently as an expert

See it in action

A full walkthrough of the paper trading feature - account creation, order placement, portfolio tracking, and the reset flow - recorded on the live Biniyog platform.

Integration over isolation: Virtual accounts share the same portfolio interface, buy/sell modal, order status tab, and fund management screen as real accounts. The only differences are the guardrails I added - hidden payment gateway for simulation deposits, market price checkbox removed for virtual orders, and a restricted menu bar that surfaces only the relevant sections. Users practice inside the real product, not a toy version of it.

06 — Key Features

Six feature areas - each a deliberate product decision.

The paper trading feature comprised six interconnected areas. Each required its own set of requirements, edge case handling, and acceptance criteria. Here is what I built and the reasoning behind each.

🏦
Virtual Account Creation & Management
Two separate creation flows - one for each account type - with clear limits on how many accounts a user can create. Account naming, account listing, and account switching all integrated into the existing portfolio dropdown. Limit indicators shown inline in the creation UI so users understand how many accounts they have remaining before they need one.
💰
Virtual Fund Management
Simulation accounts receive an automatic initial fund on creation. Fund balance tracks realistically - purchases deduct balance, sell proceeds are credited with correct settlement timing. For portfolio accounts, deposit and withdraw flows work via dummy inputs with an explicit user notice, and approvals are automatic rather than requiring admin review.
📋
Realistic Order Lifecycle
Buy and sell orders go through a full pending → executed → settlement cycle. Market price ordering is disabled for virtual accounts to enforce realistic order price discipline. Orders are matched against real intraday price ranges - an order placed at an unrealistic price simply stays pending and expires at end of day. This is the mechanic that makes the simulation genuinely educational rather than trivially easy.
📁
Portfolio Import (Virtual Portfolio)
Manual entry form and image-based OCR scan - two paths to import an existing portfolio. Trading code validation against live DSE data ensures no invalid entries. Circuit breaker checks on manually entered prices ensure the portfolio reflects realistic price points for the given trade date. Once imported, the full portfolio analytics suite is available - gain/loss, break-even price, industry exposure.
💸
Dividend Simulation
Virtual dividend credits based on actual DSE-declared dividends for held positions. Dividend amount, tax deduction, and net credit all calculated realistically - the simulation teaches users about dividend income as part of total return, not just capital gains. This was a deliberate education design choice: many retail investors underestimate the role of dividends in long-term portfolio returns.
⚙️
Commission & Reset Control
Portfolio account users can set their own brokerage commission rate - making cost tracking accurate relative to their actual broker fees. Simulation account users can trigger a full reset, returning the account to its initial funded state with a clear confirmation and disclosure. Both features give users meaningful control over the simulation's realism parameters without exposing technical complexity.
07 — Metrics

What success looked like - and the full framework I used to measure it.

North Star: Free-to-real-account conversion rate - the percentage of paper trading users who subsequently open a real BO account on Biniyog. This is the metric that connects learning behaviour to business outcome. Everything else either explains the drivers of conversion or guards against false positives.

Layer Metric Why it's on the dashboard
Acquisition New virtual account creations per week Top-of-funnel health. If paper trading is discoverable and the creation flow works, this number should grow. A plateau here signals a discovery or friction problem, not a product quality problem.
Activation % of virtual accounts placing first trade within 7 days The hardest step in any new product is getting users to their first meaningful action. A new simulation account that never places a trade has not activated. This metric is the clearest signal that users are engaging with the feature, not just creating accounts.
Engagement Average trades placed per active simulation account per week Measures depth of engagement. Users who place multiple trades per week are building trading habits - not just curiosity-clicking. High engagement correlates with confidence development, which is the precondition for real account conversion.
Engagement Session return rate - % of accounts active in 3 consecutive weeks Single-session learners don't convert to real traders. Consistent return behaviour (3+ weeks) signals that users are building a genuine practice routine. This metric distinguishes real learners from curious one-time visitors.
Conversion Paper-to-real BO account conversion rate (North Star) The core business outcome. Every paper trader who opens a real account is a long-term revenue-generating user. This is the metric that justifies the feature investment and the metric by which the team's success is ultimately measured.
Conversion Time from first virtual trade to real BO account opening Measures the velocity of the learning-to-confidence journey. If the average conversion time decreases over product iterations, the simulation is becoming more effective at building confidence. If it increases, users may need more guided support or clearer pathways to upgrade.
Quality Portfolio account import completion rate Manual portfolio import is a multi-step process. If users start but don't complete it, there is friction in the form or a data validation error causing abandonment. Tracking completion rate isolates the import flow as a distinct funnel within the broader paper trading feature.
System Order execution rate - % of simulation orders executed vs. expired Realistic order matching means some orders will expire if placed at unrealistic prices. A very high expiry rate could mean the order placement UX is confusing users about acceptable price ranges - an educational gap that affects the realism benefit the feature is supposed to deliver.

What I deliberately excluded

Virtual portfolio P&L as a success metric. A simulation account with high virtual returns tells you nothing about whether the user is learning useful skills. Users can get lucky in a simulation by concentrating in a single stock that happens to run. Tracking paper P&L as a success metric would reward luck, not learning.

Total virtual volume traded. Volume can be inflated by a small number of hyperactive users placing hundreds of small simulation trades. It says nothing about the breadth of user engagement or the quality of the learning experience for the median user. Session return rate is a more honest measure of genuine engagement.

08 — Risks

What could go wrong - and how I designed against it.

High
Simulation feels too easy, creating overconfident users who lose real money
If the simulation is unrealistically forgiving - instant execution, no slippage, no commission - users may develop false confidence that leads to poor decisions with real capital. This would harm users and damage Biniyog's reputation. Mitigated directly in the design: commission is deducted, order execution is tied to real price ranges, and market-price orders are disabled - forcing users to practise price discipline from day one.
High
Virtual accounts mistaken for real accounts by users
If the simulation is too seamlessly integrated into the real platform, users may not clearly understand they are operating in a virtual environment - particularly newer users who are unfamiliar with the interface. A user who thinks they've placed a real order but was in simulation mode could miss a real trading opportunity. Mitigated through the portfolio dropdown label, account type indicators, and contextual guidance visible within virtual account sessions.
High
Portfolio import errors corrupt the user's virtual portfolio state
Manual entry carries inherent error risk - incorrect trading codes, wrong quantities, mistyped averages. An incorrect portfolio import doesn't just produce bad analytics; it actively misleads the user about their portfolio's performance. Mitigated by trading code validation against live DSE data, circuit breaker price validation, numeric-only field constraints, and a remove-entry capability that lets users correct mistakes post-import.
Medium
Reset feature misused, destroying valid learning history
A user who resets their simulation account irreversibly loses all their trade history, performance data, and accumulated learning record. If triggered accidentally or impulsively, this could frustrate users who wanted to keep their history. Mitigated by a mandatory confirmation dialog with explicit disclosure of what reset does - including that it cannot be undone - before the operation executes.
Medium
Commission rate misconfig in portfolio account skews analytics
If a portfolio account user sets an incorrect commission rate - or leaves the default when their actual broker charges a different rate - all cost and break-even calculations will be wrong. Analytics that are systematically misleading are worse than no analytics. Mitigated by pre-filling the commission field with the platform default, adding a clear label identifying it as the user's configurable broker commission, and allowing edits at any time.
Low
Paper trading cannibilises real account opening by becoming a permanent substitute
Some users may find the simulation so comfortable that they never feel the need to open a real account - perpetually "practicing" without graduating to live trading. This is a real but lower-risk concern: the simulation is intentionally realistic enough that users eventually exhaust its novelty value. Mitigated by tracking conversion time and designing in-app prompts that surface the real BO account pathway to users with strong simulation engagement records.
09 — Lessons

What building this 0→1 taught me about product design and fintech users.

01
User segmentation at the start changes the architecture entirely
The decision to build two account types instead of one came from taking the time to understand that the three user barriers weren't variations of the same problem - they were genuinely different problems. If I had started building without that segmentation work, I would have built a simulation tool that served the majority case while leaving the portfolio management use case completely unaddressed. The upfront segmentation cost two weeks; it saved months of rework and a separate feature request cycle later.
02
Realism in a simulation is non-negotiable when the outcome is financial confidence
There was a strong internal argument for simplifying the simulation - waiving commission, allowing market-price orders, instant execution - to make it more approachable. I held the line on realism, and it was the right call. Confidence built in an unrealistic environment doesn't transfer to a realistic one. Users who practise with commission deducted, with price-range order matching, and with settlement timing learn behaviours that work in the real market. Users who practise in a simplified environment learn behaviours that don't.
03
The reset function is a product feature, not a support ticket
Before I specified the reset feature, users with irreparably messy simulation accounts would have had to contact support to request a manual data clear - a bad experience for the user and a cost for the business. By designing reset as a self-service, first-class product feature with an appropriate confirmation flow, I eliminated an entire category of support requests before they existed and simultaneously made the simulation more valuable as a reusable practice tool rather than a one-time environment.
04
Integration over isolation makes education stick
The decision to build paper trading inside the real platform interface - same buy/sell modal, same portfolio page, same analytics - rather than as a separate "learning mode" was a deliberate pedagogical choice. Users who learn on the real interface have zero relearning cost when they transition to a live account. Every interaction in the simulation is a repetition of the exact interaction they'll perform with real money. Isolation would have built fluency in a tool they'd never use again.
05
The conversion metric only makes sense if you also track its inputs
Free-to-real conversion rate was the right north star, but watching it in isolation is insufficient. If conversion drops, you need the activation rate, engagement depth, and conversion time metrics to understand why. A drop in conversion with stable engagement suggests a friction in the upgrade path. A drop in conversion with declining engagement suggests a quality problem in the simulation. The metric framework I built wasn't just for reporting - it was a diagnostic instrument for understanding where in the funnel the problem was and what kind of intervention would fix it.
Appendix - The Evidence

Functional Spec Excerpts

The requirement artefacts behind the product - user stories, acceptance criteria, and the feature activation flow as specified in the PRD.

Appendix A - User Stories
ID As a… I want… So that…
US.1 New user who has never traded before to practise placing buy and sell orders with virtual money in a real market environment I can build confidence and trading habits before risking any real capital
US.2 Experienced user who wants to test a trading strategy a simulation account that executes orders against real market prices with realistic commission and settlement I can validate whether my strategy works in actual market conditions before committing real funds
US.3 Active trader using a different brokerage to manually import my existing portfolio into Biniyog with custom trade dates and my broker's commission rate I can use Biniyog's analytics tools to track and analyse my real portfolio without switching my actual brokerage
US.4 Simulation user who has made a series of mistakes to reset my simulation account to its initial funded state and start fresh I can begin a new practice cycle without my previous errors distorting my current learning environment
Appendix B - Key Acceptance Criteria
# Criteria Owner Verified by
AC.1 A new Virtual Simulation account must be automatically funded with the defined virtual capital amount on creation - no manual deposit step required from the user. BE QA: create new simulation account, verify balance is present and correct before any user action
AC.2 Buy and sell orders in virtual accounts must not allow market-price execution. All orders require a specific price input. FE QA: open buy/sell modal under virtual account - verify market price checkbox is hidden/disabled
AC.3 Simulation orders must only execute when the order price falls within the real intraday high/low range for that trading code during the order window. BE QA: place order above day's high - verify order remains pending and expires at end of session
AC.4 Account reset must display a confirmation dialog with full disclosure of what is deleted before executing. The operation cannot be undone. FE / BE QA: trigger reset, verify confirmation text matches spec, verify all portfolio and transaction data is cleared post-confirmation
AC.5 Portfolio import trading codes must be validated against live DSE instrument data. Invalid codes must be rejected with a clear error message before any data is saved. BE QA: submit import with invalid trading code - verify save is blocked and error message is displayed
Appendix C - Virtual Simulation Account Activation Flow

How a new user goes from registration to placing their first simulated trade.

1
User registers on Biniyog
Standard registration. No changes to the existing onboarding flow. Paper trading is available immediately after registration - no broker approval or KYC required for virtual accounts.
↓
2
Open Add Portfolio modal → Virtual BO tab
User navigates to the portfolio section and opens the Add Portfolio modal. The second tab "Virtual BO" shows available virtual account types with remaining account slot indicators.
↓
3
Generate Virtual Simulation account
User clicks Generate button. Enters a Display Name (required, <255 chars) to identify the account. Clicks Create.
↓
4
Account auto-funded
System creates the virtual account and automatically credits the initial virtual capital. User's trade balance is immediately ready. No deposit step required.
↓
5
Select virtual account in portfolio dropdown
The new account appears in the portfolio selector. Selecting it activates the virtual menu context - IPO, Report, and Profile tabs hidden; buy/sell guardrails active.
↓
6
Place first simulated order
User opens buy modal, selects a stock, enters a price within the day's circuit breaker range, and submits. Order enters pending state. Executed when real market price matches the order price within the session.
↓
✓
Portfolio populated - learning begins
Executed order appears in portfolio tab with realistic commission deducted. User can now track performance, place additional orders, review order history, and analyse holdings - all within the real Biniyog interface using virtual capital.