The Hard Part of Building an AI Stock Screener Isn’t the LLM

What I learned turning vague investment ideas into structured NSE and BSE research—and why financial AI must explain its work. TL;DR People describe investment ideas as stories, while stock databases expect exact fields, operators, and time periods. Building a useful AI stock screener is therefore less about asking an LLM to “pick stocks” and more about translating ambiguous language into verifiable criteria, applying those criteria to structured data, and showing the user enough evidence to challenge the result. Disclosure: I am the builder of EasyStock, the product discussed in this article. This is a product and engineering retrospective, not investment advice.The Interface Mismatch A person researching the Indian market might begin with a question like this: Find profitable NSE and BSE companies with improving margins, low debt, and strong recent momentum. The sentence feels clear to a human. To software, almost every important word is incomplete.What counts as profitable—positive net income, positive operating cash flow, or a minimum return on equity? How low must debt be? Does “recent” mean one month, one quarter, or one year? Should momentum be measured against the company’s own history, its sector, or a benchmark?A conventional screener solves this by making the user specify every field:net_income > 0 debt_to_equity 0 price_return_90d > 10% That approach is deterministic, but it creates a usability problem. The user must already understand the data model before asking a question.A general-purpose chatbot has the opposite strengths and weaknesses. It understands flexible language, but unless it is connected to structured and current market data, a confident answer may be impossible to verify.The product problem is not choosing between a screener and a chatbot. It is designing a reliable bridge between them.Treat the LLM as a Translator, Not an Oracle The most useful mental model I found was to treat the language model as an intent translator. At a product level, a natural-language screening workflow needs to look something like this:User question ↓ Intent extraction ↓ Structured criteria ↓ Data validation and retrieval ↓ Deterministic filtering ↓ Ranking and explanation ↓ Results the user can inspect The LLM is important at the first and last stages. It can interpret what the user probably means and explain the output in a readable language. It should not silently invent the financial values in the middle.For example, the original prompt might become an intermediate representation such as:{ "market": "india", "exchanges": ["NSE", "BSE"], "hard_constraints": [ {"metric": "net_income", "operator": ">", "value": 0}, {"metric": "debt_to_equity", "operator": "<", "value": 0.5} ], "directional_preferences": [ {"metric": "operating_margin_growth", "direction": "higher"}, {"metric": "price_momentum_90d", "direction": "higher"} ], "unresolved_terms": ["strong"] } This representation is valuable even if the exact production schema looks different. It forces the system to separate what can be tested from what still needs interpretation.It also creates a place to stop and ask for clarification. If a user requests “cheap technology companies,” the system can expose the valuation metric it selected rather than pretending that “cheap” has one universal definition.Hard Constraints and Soft Signals Should Not Be the Same Thing One of the easiest ways to produce confusing results is to treat every phrase as a strict filter. Some criteria are naturally binary: Listed on NSE or BSE Positive net income Debt-to-equity below a specified value Market capitalization above a specified threshold Other criteria are better treated as ranking signals: Strong momentum High-quality earnings Attractive valuation Consistent growth Defensive business If every soft phrase becomes a hard cutoff, the screener can return nothing. If every phrase becomes a soft preference, it can return companies that violate the user’s core requirements.A better approach is to preserve the distinction:eligible_stock = passes_market_rules AND passes_explicit_financial_constraints ​ ranking_score = momentum_score + profitability_score + valuation_score + data_quality_adjustment This also improves explanations. The interface can say, “This company passed your debt and profitability requirements and ranked highly because of recent momentum,” instead of presenting a mysterious overall score.Local Market Context Is Part of the Product Adding “India” to a generic stock prompt does not automatically create an Indian stock research product. Localization affects the entire workflow: Companies may be listed on NSE, BSE, or both. Symbols and identifiers must be resolved consistently. Financial values may be displayed in lakhs and crores rather than millions and billions. Trading calendars, corporate actions, and reporting periods affect comparisons. A delayed quote and a live quote should never look identical. Sector labels and peer groups must make sense in the local market. Even language is part of the data problem. A user may mix English financial terminology with locally familiar expressions. The interface should remain forgiving without making the underlying evaluation vague.This is why I chose to build a market-specific experience rather than put a country selector on top of a completely generic interface.An Explanation Must Be More Than Generated Prose An AI-written paragraph can sound convincing while saying very little. For a screening result, a useful explanation should answer four questions: Which user criteria did the company satisfy? Which data points were used? What time period does the result represent? What information is missing or uncertain? That means the prose should be downstream of the evidence. The ideal direction is:evidence → evaluation → explanation Not:company name → plausible-sounding paragraph Other builders of financial AI systems have reached a similar conclusion. A HackerNoon tutorial on building a financial copilot that tests stock theses, creates structured evidence layers before producing a verdict. Another implementation of a real-time AI stock advisor focuses on the retrieval and data infrastructure surrounding the model.The common lesson is that the LLM is only one component. Data lineage, validation, and output structure are what make the result useful.What I Shipped in EasyStock I applied these product principles while building EasyStock for people researching Indian listed companies. The current workflow has three main parts.First, the user describes the companies, market signals, or financial characteristics they want to find. The product converts that request into a screen and returns a structured shortlist with relevant market information.Second, the result explains why each company matched instead of showing ticker symbols without context.Third, a user can select an individual stock for a deeper AI-assisted research view that brings together available price information, financial indicators, related news, trend analysis, and risk signals.The product also supports optional position context, such as available funds, holding cost, and number of shares. That makes the output more relevant to the scenario, but it also creates an important design responsibility.More context should not create false certainty.The Boundary Between Decision Support and Advice Financial products become riskier as their outputs become more personalised and more actionable. There is a meaningful difference between these two statements: This company matched the profitability and momentum criteria in your screen. and: You should buy 50 shares today. The second statement depends on far more than market data. It may require knowledge of the user’s goals, time horizon, income, liquidity needs, total portfolio, loss capacity, and risk tolerance.This is not only a UX concern. In India, personalised financial guidance is a regulated activity, and investors are encouraged to use appropriately registered professionals. SEBI provides a public explanation of the role and requirements of registered investment advisers.For an AI research product, a footer disclaimer is not enough. The product design itself should reduce overconfidence: Do not execute trades. Timestamp market snapshots. Distinguish facts from model interpretation. Make assumptions visible. Avoid guaranteed-return language. Show when relevant data is unavailable. Encourage independent verification. The goal is not to make the output sound timid. It is to make its confidence proportional to the evidence.Five Lessons From Building the First Version 1. Example prompts are part of the interface A blank natural-language box looks simple, but it can be intimidating. Users often do not know what the system can understand. Examples such as “companies near their 52-week high with strong volume” or “profitable businesses with expanding margins” teach both the product vocabulary and the expected level of detail.2. The system should reveal its interpretation If “low debt” becomes debt-to-equity below 0.5, show that choice. A user may disagree, and disagreement is useful feedback. Hidden interpretation creates apparent precision. Visible interpretation creates a conversation.3. Loading states should describe real work AI products can take longer than conventional form submissions. A generic spinner makes the delay feel arbitrary. Stages such as “retrieving market data,” “checking financial indicators,” and “generating the explanation” give users a better mental model. These labels should correspond to real stages, not theatrical progress messages.4. No result is sometimes the correct result Relaxing constraints until something appears makes the interface feel productive, but it can quietly violate the original question. If no company passes the hard constraints, the product should say so. It can suggest which condition removed the most candidates, but it should not change the request without permission.5. Trust is a product feature In many consumer applications, a small error is annoying. In financial software, an unexplained error can change a decision. Source visibility, timestamps, consistent units, clear limitations, and reproducible filters are not secondary details. They are core features.A Practical Checklist for Financial AI Builders Before shipping a natural-language financial research feature, I would now ask: Can every numerical claim be traced to a data field? Are current facts separated from model-generated interpretation? Does the system distinguish hard filters from ranking preferences? Can the user see how the ambiguous language was translated? Are timestamps and data freshness visible? What happens when data sources disagree? What happens when no companies match? Can the user challenge or edit the interpreted criteria? Does the product communicate uncertainty without hiding behind generic disclaimers? Is there a clear boundary between research support and trade execution? If the answer to several of these questions is “no,” improving the prompt is unlikely to solve the underlying problem.Where I Want to Take It Next The next improvements I care about are not simply longer AI answers. I want screening explanations to become more inspectable: clearer criterion-level evidence, better handling of time horizons, more visible data freshness, and easier ways for users to modify the system’s interpretation.I am also interested in how users naturally describe Indian-market investment ideas. The vocabulary people use can reveal which conventional screener concepts are unnecessarily difficult and which ambiguities genuinely require clarification.If you research NSE or BSE companies, you can try EasyStock and test it with a screen you would normally construct by hand. I am particularly interested in cases where the system misunderstands a term, applies the wrong time horizon, or produces a result that is difficult to verify.Those failures are more useful than generic praise because they show where the bridge between language and data is still incomplete.Final Thought The promise of natural-language financial software is not that an LLM can predict the market. It is that software can remove unnecessary translation work between a person’s question and the evidence needed to investigate it.That only works when the language model is surrounded by deterministic checks, structured data, transparent assumptions, and a user interface designed for disagreement.The LLM may be the most visible part of an AI stock screener. It is not the part that makes the product trustworthy. Disclaimer: This article is for informational and educational purposes only. It does not constitute investment advice, a research recommendation, or an offer or solicitation to buy or sell securities. AI-generated financial information can be incomplete or incorrect. Verify information independently and consult a qualified, SEBI-registered professional where appropriate. Investments in securities markets are subject to market risks.