AI Product Fintech Investment Intelligence Biniyog.com.bd

AI Company
Recommendation
Engine

How I transformed Biniyog's analytical data into a full-stack investment decision engine - delivering personalised BUY/HOLD/SELL signals, multi-method target prices, risk scores, and automated watch alerts for every company on the DSE.

350+
DSE companies covered with daily recommendations
4methods
Target price calculation - P/E, Technical, Fair Value, DCF
6types
Proactive watch conditions monitoring market opportunities
All metrics
Feature drove meaningful gains across engagement and retention
01 — Background

Company Analysis surfaced insights. Recommendations needed to tell investors what to do with them.

Biniyog.com.bd had already shipped a comprehensive three-layer Company Analysis product - fundamental rankings, technical indicators, and AI sentiment scores for every company on the Dhaka Stock Exchange. Users could see how a company scored on each dimension. What the product couldn't yet answer was the question that sits one step further: "Given everything I know about this company right now - should I buy, hold, or sell?"

That gap mattered enormously. A retail investor staring at a fundamental score of 78, a technical score of 65, and a neutral sentiment reading still faced a decision problem: these signals were pointing in broadly the same direction, but without a synthesised recommendation, the cognitive load of translating scores into action sat entirely on the user. Many investors simply didn't act - not because the data wasn't valuable, but because the final interpretive step was too demanding.

I proposed the AI Recommendation Engine as the natural next layer above Company Analysis: an intelligent system that consumed all available analytical signals, applied market-condition-aware weighting, and surfaced a clear, defensible investment recommendation - complete with a target price, a risk assessment, a stop-loss level, and proactive alerts when conditions changed.

The product vision: Close the gap between "I understand this company" and "I know what to do." Build a recommendation engine that functions as a systematic investment analyst running 24 hours a day across every company on the DSE - delivering institutional-quality recommendations to retail investors who previously had nothing comparable.


02 — Problem

Four distinct gaps stood between analytical data and confident investment action.

User research and behaviour analysis from the Company Analysis feature pointed clearly to four unsolved problems. Each required a different type of capability to address.

01
Scores without a verdict
Users understood what each layer's score meant individually. What they couldn't do was weigh them against each other. Should a company with excellent fundamentals but weak technicals be bought today? The synthesis layer - the engine that aggregates signals into a single actionable recommendation - simply didn't exist. Users were left doing mental arithmetic across three different scoring systems with no guidance on the relative importance of each.
02
No target price or upside calculation
Even when an investor decided to buy, they had no anchored target price to manage the position against. Professional investors use target prices to define entry logic, position sizing, and exit criteria. Without a target price, users had no way to assess whether a stock was trading at a discount, fairly, or at a premium to its estimated value - one of the most fundamental inputs to any investment decision.
03
Risk was invisible until it was too late
The platform showed no explicit risk assessment at the individual company level. Users had no way to know whether a given recommendation carried low volatility risk with strong liquidity, or whether the upside came attached to a high-beta stock with concentration in a sector under pressure. Without a risk score, users couldn't make informed decisions about position size or portfolio allocation. Risk was the missing dimension in every recommendation context.
04
No protection logic for active positions
Retail investors often enter positions with no pre-defined exit strategy for downside scenarios. Professional traders set stop-losses before they open a trade; most retail investors in Bangladesh didn't have the tools or methodology to do this systematically. The absence of automated stop-loss recommendations meant users were exposed to unmanaged downside risk on every position - a gap that eroded trust when market conditions deteriorated sharply.

03 — My Approach

Six product decisions made before architecture, engineering, or design.

01
Define the market-condition-aware weighting model myself
The core question in building any composite recommendation system is: how much should each signal type matter? I defined a three-regime weighting model - bull market, bear market, and high-volatility - with fundamentals, technicals, and sentiment each carrying different weights depending on which regime the market was in. In a bull market, fundamentals dominate. In high volatility, technical signals get heavier weight because they react faster to price reality than financial statements can. This wasn't a data science decision; it was a product framework decision grounded in how professional analysts actually adjust their models across market cycles.
02
Specify four target price methodologies, not one
A single target price methodology gives false precision. Every valuation method carries implicit assumptions about what drives a stock's fair value. I specified four methods - P/E-based, technical resistance levels with Fibonacci projections, book value fair value, and discounted cash flow - each producing an independent target, which are then confidence-weighted into a final number. This approach surfaces disagreement between methods (a useful signal in itself) and gives the recommendation a confidence score that reflects how aligned the different analytical lenses are.
03
Build risk as a multi-component score, not a binary flag
A simple "high/low risk" label is too blunt to be useful for investment decisions. I specified five distinct risk components: market risk (beta), sector risk, liquidity risk, volatility risk, and fundamental financial health risk. Each component is calculated independently and aggregated into an overall risk score from 0–100, mapped to four categories. This allowed the recommendation to explain why something is risky, not just that it is - a distinction that meaningfully changes how investors think about position sizing.
04
Build stop-losses into every recommendation by default
The decision to include stop-loss calculations in every recommendation (not as an optional tool) was deliberate. Making it default changes how investors think about entering positions: a recommended entry comes pre-packaged with a suggested exit level, forcing risk management to be part of the investment thesis from the outset rather than an afterthought. Three calculation methods - ATR-based, volatility-based, and support/resistance-based - are weighted and merged into a single recommended level with a stated confidence score.
05
Design watch conditions as proactive alerts, not passive labels
A WATCH recommendation that just sits on a company card is passive. I specified six watch condition types - technical breakout, sector rotation, fundamental improvement, price consolidation, momentum building, and volume anomaly - each with its own trigger criteria and alert priority. When conditions are met, users are proactively notified; the system monitors every company every day and surfaces the ones where something meaningful has changed. This shifted the recommendation engine from a reference tool to an active monitoring system.
06
Own the API contract as a product requirement
I specified the full API response structure for every endpoint before engineering started. This wasn't a technical exercise; it was a product decision about what data the frontend needed to render a complete, actionable recommendation card without making additional calls. Pre-computing everything and serving it via sub-200ms cached responses meant recommendation pages loaded instantly on mobile - critical for investors checking positions before the market opens.

04 — Recommendation Logic

A market-aware composite engine - not a static formula.

The recommendation engine's core innovation was that signal weights weren't fixed - they shifted based on what type of market environment the system detected. Each day, the engine first classified the market condition (bull, bear, or high-volatility) by analysing index behaviour, volatility indices, and volume trends. That classification then determined how the three analytical layers were weighted in the composite score.

Market-Condition Adaptive Scoring
Bull Market Weights
Fundamental Analysis
40%
Technical Analysis
35%
Market Sentiment
25%
High-Volatility Market Weights
Technical Analysis
60%
Fundamental Analysis
25%
Market Sentiment
15%

The composite score maps to four recommendation categories. I defined the buy/hold/sell thresholds for each market regime independently, recognising that a score of 65 means something different in a bull market than in a bear market.

SignalThreshold (Bull)Meaning for the investorFollow-up output
BUY ≥ 70 composite score Strong alignment across fundamental quality, technical momentum, and sentiment. High-conviction opportunity. Target price, stop-loss level, risk score, upside %
HOLD 50–69 Mixed or moderate signal alignment. Not the right moment to add or exit; maintain existing position. Updated target price, risk monitoring
SELL < 30 Deteriorating fundamentals, negative technical momentum, or poor sentiment converging. Exit or reduce position. Stop-loss breach alert, risk escalation
WATCH Condition-triggered A specific emerging signal (breakout pattern, sector rotation, consolidation) warrants monitoring before acting. Condition type, confidence score, alert priority

Why variable thresholds matter: A sell threshold of 30 in a bull market becomes 25 in a bear market - because in a down market, more companies will naturally score lower and a blanket sell signal would create panic rather than clarity. The thresholds encode market context, not just mathematical cutoffs.


05 — Four Pillars

Every recommendation is backed by four independently calculated components.

I specified four distinct analytical services, each solving a different investor question. Together they form a complete decision package - not just a signal, but the supporting rationale an investor needs to act with confidence.

Pillar 01
Target Price
Answers: "What is this company actually worth?"
P/E Method Technical Levels Fair Value DCF
Four independent valuation methodologies each produce a standalone target price. A P/E-based calculation uses industry-adjusted earnings multiples against forward EPS. A technical method identifies resistance breakout levels using Fibonacci retracement projections. A fair value method applies sector-specific asset multipliers to book value per share. A DCF model projects discounted cash flows using a calculated growth rate and risk-adjusted discount rate. Each method produces its own confidence score based on data quality and input availability. The final target price is a confidence-weighted average - meaning a high-quality P/E calculation gets more influence than a DCF built on sparse cash flow history.
Pillar 02
Risk Assessment
Answers: "How much risk am I taking on?"
Market Risk Sector Risk Liquidity Risk Volatility Risk Fundamental Risk
A five-component risk model, each calculated independently and aggregated into a 0–100 composite risk score. Market risk uses a 252-day beta calculation against the DSE index. Sector risk combines sector volatility, concentration, and trend stability over a 90-day window. Liquidity risk assesses average daily trading volume, volume variability, and market cap tier. Volatility risk measures historical price volatility, stability patterns, and volatility trend direction. Fundamental risk evaluates debt-to-equity, current ratio, and interest coverage. The composite score maps to four risk categories: LOW, MEDIUM, HIGH, VERY HIGH - each with specific beta ranges and volatility characteristics defined in the product spec.
Pillar 03
Stop-Loss Level
Answers: "Where do I get out if I'm wrong?"
ATR Method Volatility Method Support Method
Three calculation methodologies, each weighted by confidence. The ATR-based method uses the 14-day Average True Range multiplied by a market-condition-adjusted multiplier (ranging from 1.5× in calm markets to 2.5× in high volatility). The volatility-based method calculates annualised historical volatility and places the stop 1.5 standard deviations below current price. The support-based method identifies structural price support levels over a 50-day window and places the stop 2% below the nearest meaningful level. The weighted average of the three methods produces the recommended stop-loss price, accompanied by a confidence score that reflects how consistently the three methods agree.
Pillar 04
Watch Conditions
Answers: "What should I be watching for?"
6 Condition Types Proactive Alerts 87% Effectiveness
Six distinct watch condition types, each with independently specified trigger criteria, confidence thresholds, and historical effectiveness targets. This pillar is described in detail in the next section. The key design decision was making watch conditions proactive alerts rather than passive labels - when trigger criteria are met, users are notified with context on what changed, why it matters, and what action to consider. This transformed the recommendation engine from a daily report into a real-time monitoring system.

06 — Watch Conditions

Six signal types. Each monitors something different. All running daily across every company.

The watch conditions system was one of the highest-leverage features I specified in this product. Rather than requiring users to manually screen for opportunities, the engine monitors all 350+ companies every day against six distinct patterns - and surfaces the ones where something actionable has developed.

I defined each condition type with specific trigger criteria (a minimum number of sub-conditions that must be satisfied), a confidence calculation methodology, and an alert priority rating. The system was designed to be explainable: when a condition triggers, users see exactly which criteria were met, not just a "WATCH" label.

90%
Technical Breakout
RSI recovery from oversold, MACD crossover, Bollinger Band bounce, and volume confirmation. Triggers when 3 of 4 criteria are met.
90%
Price Consolidation
Price range below 5% over 10 days, stable volume, duration above 7 sessions, and proximity to a resistance level.
88%
Momentum Building
RSI trending upward in the 50–70 band, positive MACD, bullish stochastic, price above 20-day MA, rising volume.
85%
Sector Rotation
Sector outperforming the broader market by 10%+, accelerating momentum, confirmed inflow signal, and high relative strength.
85%
Fundamental Improvement
Sustained score improvement over 90 days, consistency across three prior periods, above-average absolute score, and positive earnings growth.
75%
Volume Anomaly
Volume spike greater than 2× the 30-day average, price movement confirmation, and sustained elevated volume over three sessions.

On the 75% effectiveness floor: The Volume Anomaly condition was the most difficult to specify precisely - unusual volume can indicate institutional accumulation or distribution, and the signal is inherently ambiguous without confirming price action. I set a lower confidence threshold (50% of sub-conditions vs 75% for other types) to ensure it triggered more frequently, with a lower alert priority, to surface the signal without over-weighting it. The PM's job is choosing the right tradeoff, not demanding 90% everywhere.

Condition prioritisation framework

Not all triggered conditions are equal. I specified an alert priority matrix that combined condition effectiveness with confidence score and market context. A Technical Breakout with 90% confidence triggering in a bull market gets a HIGH priority alert. The same condition triggering with 60% confidence in a high-volatility market gets a MEDIUM priority alert. The priority matrix ensures users pay attention to the signals most likely to be actionable - not just the signals that technically crossed a threshold.


07 — Outcomes

Every metric moved in the right direction. Including the ones hardest to move.

The AI Recommendation Engine was one of the most successful feature launches in Biniyog's history. The product performed strongly across engagement, retention, and trust metrics.

87%
Overall watch condition effectiveness across all six signal types
<200ms
API response time for all recommendation endpoints serving 350+ companies
4–6 min
Daily processing time to generate fresh recommendations for all companies
Engagement

Session depth increased meaningfully

Users who accessed the Recommendation Engine viewed significantly more company pages per session than pre-launch baselines. The recommendation card became the anchor for deeper exploration - target price led to company analysis, which led to portfolio action.

Retention

Weekly active user uplift sustained

Watch condition alerts drove meaningful return visits. Users who received at least one triggered watch alert in a week showed substantially higher 30-day retention than those who didn't. Proactive notifications created a re-engagement loop that passive features couldn't replicate.

Trust

Confidence in recommendations rated highly

Post-launch user feedback consistently cited target price transparency and the multi-method breakdown as trust drivers. Users appreciated seeing not just the number, but which methodologies agreed - and which disagreed. Explainability built credibility.

Adoption

Rapid adoption across user cohorts

The recommendation feature had one of the fastest adoption curves of any Biniyog feature. Both experienced investors (who valued the risk breakdown) and newer users (who relied on the BUY/HOLD/SELL signal) found immediate utility at different levels of depth.

The compounding effect: Company Analysis, Technical Rankings, and the Recommendation Engine were designed as a stack. Each feature made the ones below it more valuable. Users who started with Company Analysis and discovered Recommendations became the highest-engagement cohort on the platform. The whole was significantly greater than the sum of the parts.


08 — Risks & Tradeoffs

Every significant decision came with a tradeoff I had to consciously choose.

Risk

Recommendations could be misread as guarantees

A BUY signal on an individual stock carries no guarantee of returns. Risk: users might over-allocate based on the signal without reading the risk score or stop-loss. Mitigation: confidence scores, risk category labels, and plain-language caveats designed into every recommendation card.

Risk

Market condition misclassification

If the system classifies a volatile market as a bull market, weights shift incorrectly and signals degrade. Mitigation: market condition detection uses multiple independent signals (volatility index, trend direction, volume patterns) requiring agreement before reclassifying.

Risk

Watch condition alert fatigue

Triggering too many alerts across 350+ companies could desensitise users. Mitigation: a three-tier alert priority system (LOW / MEDIUM / HIGH) with daily caps and a progressive disclosure model that surfaces only the highest-priority conditions first.

Risk

Data quality degrading recommendation accuracy

A recommendation is only as good as its input signals. If fundamental data is stale or sentiment data is sparse, the composite score degrades invisibly. Mitigation: every recommendation card displays a data quality score and a "data freshness" timestamp, making input reliability visible to users.

The deliberate tradeoffs

Tradeoff 01

Complexity vs. explainability

A simpler model (one signal, one weight) would be easier to explain but less accurate. I chose complexity with explicit transparency - every component of the recommendation is surfaced, not hidden behind the final signal.

Tradeoff 02

Coverage vs. depth

350+ companies means some will have sparser data than others. I chose full coverage with confidence scoring over restricting recommendations to the highest-data-quality companies, ensuring users aren't left without guidance on specific stocks they hold.

Tradeoff 03

Daily refresh vs. real-time

Real-time recommendations would require significantly more infrastructure and introduce latency risk. I chose daily pre-computation with <200ms serving - fast enough for most investment decisions, with intraday alerts as a future enhancement roadmap item.


09 — Lessons

Five things I'd do the same. One I'd do differently.

01
AI product management means owning the logic, not just the interface
The most important decisions in this project weren't about what the screen looked like. They were about how signals should be weighted, what thresholds distinguish a BUY from a HOLD, how risk components should aggregate, and what makes a watch condition worth triggering. These are product decisions that require domain knowledge, user empathy, and analytical judgment - not engineering expertise. The PM who treats these as "data science tasks" loses ownership of the feature's most critical behaviour.
02
Adaptive models beat static models for market products
The most meaningful architectural decision was making the weighting model market-condition-aware. A static 40/35/25 weight across all market conditions would have produced nonsensical recommendations during high-volatility periods when fundamental scores lag price reality by weeks. Designing adaptivity into the core model from day one - rather than as a future refinement - was the right call, even though it added specification complexity upfront.
03
Explainability is a product feature, not a UX afterthought
The decision to surface multi-method target price breakdowns, five-component risk scores, and per-condition watch trigger criteria wasn't a UX preference - it was a trust-building product strategy. Users who could see why a recommendation was made engaged with it more deeply and acted on it more confidently than they would have if shown a black-box signal. Explainability should be designed into the product specification, not added after engineering completes.
04
Proactive beats reactive at every engagement metric
The watch conditions system, which pushed alerts to users rather than waiting for them to check, drove measurably higher engagement and retention than any passive feature. When building for investment contexts - where timing matters and users are busy - a product that comes to the user rather than waiting for the user to come to it is structurally more valuable. The lesson generalises: wherever timing matters to the user's outcome, proactive design outperforms reference design.
05
Performance is a product quality requirement, not an engineering SLA
I set the sub-200ms API response target as a product requirement in the spec, not a post-launch optimisation target. The discipline of pre-computing recommendations and serving them from cache - rather than computing on request - was a direct result of treating performance as a product requirement. If the feature had been slow, the signal quality would have been irrelevant: investors checking positions at 9:45 AM don't wait for a page that takes 3 seconds to load.
06
What I'd do differently: earlier user testing on the recommendation card layout
The recommendation card contained a lot of information - signal, target price (with four sub-prices), risk score (with five components), stop-loss, and watch conditions. I specified the data requirements thoroughly but left the information hierarchy decisions primarily to design. In retrospect, I should have run lightweight user tests on how investors naturally prioritise these elements when making a decision - their mental model of "what do I need to see first" may not match my assumption that the signal label was the anchor.
Appendix — The Evidence

Functional Spec Excerpts

User stories, acceptance criteria, and the full data-to-recommendation pipeline as specified in the product requirements.

Appendix A — User Stories
IDAs a…I want…So that…
US.1 Retail investor reviewing my watchlist each morning a clear BUY / HOLD / SELL signal for each company backed by a visible composite score I can make a decision in under a minute without manually synthesising multiple scores
US.2 Investor considering entering a new position a target price with a breakdown of the methods used and how much they agree I can assess whether the current price represents a meaningful discount to fair value
US.3 Investor who wants to manage downside risk a recommended stop-loss level with a stated rationale I enter every position with a pre-defined exit plan rather than deciding under pressure
US.4 Investor monitoring companies I don't currently hold proactive alerts when a specific pattern develops that makes a company worth acting on I don't miss time-sensitive opportunities because I wasn't actively checking the platform
US.5 Investor who wants to understand how much risk I'm taking a risk score that breaks down market, sector, liquidity, volatility, and fundamental risk separately I can make position-sizing decisions based on the specific type of risk, not just a single number
Appendix B — Key Acceptance Criteria
#CriteriaOwnerVerified by
AC.1 Composite recommendation scores must produce a realistic distribution across BUY, HOLD, SELL, and WATCH categories. No single category should contain more than 50% of companies in a given market condition. BE QA: verify distribution report after each daily run; alert if any category exceeds 50% of total
AC.2 All recommendation API endpoints must return responses in under 200ms at the 95th percentile. Daily recommendation generation for all companies must complete within 6 minutes. BE Load test: 100 concurrent API requests measured; daily processing time logged with wall-clock measurement
AC.3 Every target price must display all four component prices, their individual weights and confidence scores, and a data quality indicator. The final target price must never be shown without this supporting breakdown. FE Design review: all four sub-prices and confidence scores visible without expanding; data quality indicator displayed
AC.4 Watch condition alerts must specify the condition type, the specific criteria that triggered, the confidence score, and the alert priority. No alert is sent without all four fields populated. BE / Notifications QA: trigger a known watch condition in staging; verify all four fields present in notification payload
AC.5 The risk score breakdown must display all five risk components (market, sector, liquidity, volatility, fundamental) with individual scores and the overall risk category. No overall risk category is shown without component detail accessible. FE QA: verify all five components visible on expanded risk view; overall category present on collapsed view
Appendix C — Data-to-Recommendation Pipeline

How the system processes raw analytical signals every day and delivers a complete, actionable recommendation to a Biniyog investor.

1
Market condition detection (6:00 PM daily)
DSE index data, volatility index, and volume trends analysed. Market classified as BULL, BEAR, or HIGH_VOLATILITY. Signal weights for the day's run are set based on detected condition. Market state saved for API reference.
2
Sector performance analysis
Sector returns calculated and compared against market baseline. Rotation signals (INFLOW / OUTFLOW) determined per sector. Sector risk and momentum scores updated for use in company-level risk assessment and watch condition evaluation.
3
Company data loading (350+ companies)
Four data streams loaded in parallel per company: fundamental scores and financial metrics, technical indicator values, daily price and volume data, and sentiment scores. Data quality assessed per company; confidence scores assigned based on completeness.
4
Four-pillar calculation engine
Target price: four methods calculated, confidence-weighted, final price and justification generated. Risk: five components scored, aggregated to overall risk score and category. Stop-loss: three methods calculated, weighted average computed. Watch conditions: six condition types evaluated against trigger criteria for each company.
5
Composite score and recommendation generation
Market-condition-weighted composite score calculated from fundamental, technical, and sentiment inputs. Composite score mapped to recommendation (BUY / HOLD / SELL / WATCH) using market-specific thresholds. Category rankings generated across all companies and by sector.
6
Storage, cache, and alert dispatch
Recommendations saved to primary table; historical record archived. Cache populated for all API endpoints. Watch condition alerts evaluated for priority and dispatched to eligible users. Full pipeline completes in 4–6 minutes for all companies.
Investor sees a complete, actionable recommendation
BUY / HOLD / SELL / WATCH signal · Composite score with market context · Target price with four-method breakdown and confidence · Risk score across five components with category label · Stop-loss level with rationale · Active watch conditions with trigger criteria and priority · All served in under 200ms.