AI Financial Intelligence Platform

A multi-agent research system for equity analysts that automates company screening across fundamentals, market performance, and news sentiment—producing ranked, evidence-backed results with automated review. Try the Platform

1. Problem & Solution

The Problem

Equity analysts spend significant time gathering company data, reviewing news, and comparing investment candidates. Automating this work introduces a second problem: financial AI can fail silently. Even when it retrieves evidence about the wrong companies, it may produce a fluent, confident, and properly cited answer.

The Solution

The platform retrieves and ranks evidence across structured fundamentals, financial news, and market APIs, then verifies grounding, citations, and hallucination risk. Reliability is measured through a 100-question benchmark covering routing, retrieval, SQL correctness, ranking, and answer quality—while the analyst retains responsibility for the final investment decision.

2. System Design

Production deployment architecture in three bands. Band one, the application and query path: an analyst or admin in a browser reaches an Application Load Balancer on *.sathwikap.com over HTTPS 443 with a wildcard ACM certificate and HTTP 80 redirected to 443. The balancer forwards to an ECS Fargate API service, task definition fip-prod-api:v4, holding four containers or components: FastAPI serving REST APIs under /api/*, the React UI served as static files by FastAPI, in-app JWT auth using JWT_SECRET and require_role, and a Redis 7 sidecar on localhost:6379. Inside the same service the LangGraph workflow runs intent planner, SQL vector and market retrieval, reranker using BM25 and RRF, scoring, analysis, reviewer and final response. The service reads and writes two data stores: Amazon RDS for PostgreSQL with pgvector holding market data, users, metadata, vectors and financial data, and Amazon S3 holding raw documents from SEC EDGAR and admin uploads. Band two, shared AWS services: Amazon ECR container registry serving fip-prod-app:v4 images for the API and worker, AWS Secrets Manager holding eight application credentials with no AWS keys stored, AWS ACM providing the TLS certificate, and Amazon CloudWatch Logs with log groups for the api and worker. Band three, the ingestion and indexing pipeline: SEC EDGAR filings, admin uploads, Alpha Vantage or Finnhub news and Yahoo Finance metrics feed either an S3 raw bucket or a seeding script that writes directly to RDS. From the raw bucket documents pass to an SQS main queue, with a dead-letter queue for failed messages, and on to an ECS Fargate worker, task definition fip-prod-worker:v4, which downloads from S3, OCRs, normalises and chunks, embeds, and upserts vectors directly into Amazon RDS. — **Production Architecture**

LangGraph workflow. A user's natural-language financial question passes to an intent classifier (valuation, growth, sentiment, mixed), then a query planner that builds queries and selects a retrieval strategy. Retrieval fans out to three sources in parallel: SQL metrics (P/E, EPS, revenue), vector documents (earnings, SEC filings, news), and a market API (prices, trends, live data), with a Redis layer holding a market-data cache (ticker keyed, 5 minute TTL) and an embedding cache (text plus model hash, 30 day TTL). Results flow to a scoring engine (valuation, growth, relevance, sentiment), a reranker doing hybrid evidence ranking, then LLM analysis that explains the rankings in an evidence-grounded report. A reviewer node checks for hallucination, evidence, citations and confidence, and can loop back to re-retrieve or re-analyze; when confidence falls below 0.30 or the retry limit is reached it escalates to human admin review. The final output is ranked companies with evidence, confidence, and review status. — **LangGraph Workflow**

3. Analyst Interface Demo

4. Admin Interface Demo

5. Evaluation & Benchmarking

6. Observability

LangSmith

AWS CloudWatch

7. Security & GuardrailsPII · Prompt-Injection Detection · LLM-Based Guard · Rate Limiting · Output Validation

8. Engineering Outcomes

Grounding improvement: Raised faithfulness from 0.64 → 0.75 on a fixed 25-question set by tracing grounding failures to a generation-prompt instruction, verified against a measured 0.04 run-to-run noise floor, with unsupported comparative claims falling 56 → 1.
Retry-path redesign: Reduced retrieval executions from 3.28 → 1.00 per question after identifying that retries reran identical queries against an unchanged corpus and therefore could not converge.
Evaluation correctness: Found retrieval precision was scoring live market rows alongside document chunks and separated the metric inputs so retrieval quality is measured against the document corpus alone.
Reproducible evaluation: Froze the corpus and embeddings after live market-data changes altered ranking membership and caused correct results to be graded incorrectly.
Deployment optimization: Reduced deploy payload from 4.36 GB → 164 MB by reusing base-image layers and chunking registry uploads after three standard tools failed identically on the same upload.

9. Technology Stack

Language & API: PythonFastAPI
Orchestration: LangGraph
Models: OpenAIAnthropicGemini
Data: PostgreSQL + pgvector (HNSW)Redis
Evaluation & tracing: RAGASLangSmith
Interface: React
Infrastructure: AWS ECS FargateAmazon RDSAmazon S3Amazon SQSTerraformDocker

10. Key Design Choices

Intent-routed retrieval: A classifier routes each question to SQL, document search, market data, or a combination, so a valuation question queries the database while a sentiment question searches the corpus.
Hybrid dense + lexical search: pgvector similarity and BM25 run in parallel, merged by reciprocal rank fusion, then reranked by a cross-encoder; both stages are per-run flags so retrieval arms can be benchmarked against each other.
Provider-agnostic model layer with a fixed evaluation judge: Providers and their model tiers are resolved from the database at request time, while the benchmark judge stays pinned to one model, so a run against OpenAI and a run against Anthropic are graded identically and remain comparable.
Per-stage evaluation with claim-level grounding checks: Six evaluators score intent, tool use, SQL, retrieval, ranking and market data independently, and a seventh decomposes each answer into atomic claims and verifies every one against the evidence actually retrieved — so a failure is attributable to a stage rather than to the system.
Reviewer/retry loop: A reviewer node checks the draft for unsupported claims and invalid citations and routes a retry back to the only stage whose inputs can differ, carrying the flagged claims forward so the next attempt has something new to work with.