B. P.

Mandal College of Engineering

Madhepura (Bihar) - 852128
Affiliated to
Bihar Engineering University Patna, (Bihar), India.

A
Project Report
on
AUTOSTOCKS: AUTOMATED WEEKLY STOCKS REPORTING
SYSTEM
for the award of

BACHELOR OF TECHNOLOGY
in
COMPUTER SCIENCE & ENGINEERING

Submitted by -
SOURAV KUMAR (21105128012)
RITIK (21105128046)
ANUSHKA SAUMYA (21105128024)

Under The Supervision

of
Prof. Praveen Kumar
Assistant Professor
Computer Science & Engineering
B. P. Mandal College of Engineering, Madhepura (2021 – 2025)

1
 Dedicated to
My Parents, Teachers, and Friends.

2
 DECLARATION

I declare that the project entitled “AutoStocks: Automated Weekly Reporting System for
Stocks, Crypto, and Mutual Funds” is our work conducted at B. P. Mandal College of
Engineering Madhepura (Bihar), approved by the Committee. I have attended more than
90 days of attendance with the Supervisors at the B. P. Mandal College of Engineering,
Madhepura.

I further declare that, to the best of our knowledge, the report does not contain the work
which has been submitted for the award of the degree either in the University or in any
other University/Deemed University without proper citations.

S. No. Name of Students Registration Number Signature

1 SOURAV KUMAR 21105128012

2 RITIK 21105128046

3 ANUSHKA SAUMYA 21105128024

Dated: ………………….

Place: MADHEPURA

3
 B. P. Mandal College of Engineering
Madhepura (Bihar) - 852128
Affiliated to
Bihar Engineering University Patna, (Bihar), India.

CERTIFICATE
This is to certify that the project report entitled “AUTOSTOCKS: AUTOMATED WEEKLY
REPORTING SYSTEM FOR STOCKS, CRYPTO, AND MUTUAL FUNDS” is a piece of
project work done by SOURAV Kumar (21105128012) , RITIK (21105128012) ,
ANUSHKA SAUMYA (21105128024) under our guidance and supervision for the
completion of 8th Semester, Bachelor of Engineering of B. P. Mandal College of Engineering,
Madhepura, Bihar (India). The candidate has put in the required attendance of more than 90
days with me. To the best of our knowledge and brief the project.

I. Embodies the work of the candidate himself.

II. Has duly been completed.
III. Is up to the standard both in respect of contents and language for being referred to
the examiner.

Prof. Praveen. Kumar Prof. Murlidhar Prasad Singh

Project Guide Head of Department
Computer Science & Engineering Computer Science & Engineering
B. P. Mandal college of Engineering, B. P. Mandal college of Engineering,
Madhepura Madhepura

Prof. Arbind Kumar Amar

Principal
B. P. Mandal college of Engineering,
Madhepura

Date
Place

4
 B. P. Mandal College of Engineering
Madhepura (Bihar) - 852128
Affiliated to
Bihar Engineering University Patna, (Bihar), India.

ACKNOWLEDGEMENT
We express our sincere thanks to our respected project supervisor Prof. Praveen Kumar,
Assistant Professor, Department of Computer Science and Engineering, B. P. MANDAL
COLLEGE OF ENGINEERING, MADHEPURA for her guidance, encouragement and
motivation towards real-time research work right from the beginning of the research up to
the completion of this dissertation. It was a pleasure to work under his supervision. She
was always available with new ideas and suggestions during the difficult phases of our
dissertation. All the help is gratefully acknowledged. We sincerely thank Prof. Murlidhar
Prasad Singh, as the Head of the Department of Computer Science & Engineering, for
their kind support and permission to use the facilities available in the institute. We would
like to extend our thanks to all the lab assistants who have been there whenever we needed
the resources.

Our thanks go to all the staff of the Department of Computer Science and Engineering.
B. P. MANDAL COLLEGE OF ENGINEERING, MADHEPURA for their continuous
support throughout the dissertation work. Last, but not least. We also want to give a
warm thanks to all our classmates and non-technical staff. Without their thankful hand
we could never complete our dissertation successfully.

Date: 1. SOURAV KUMAR (21105128012)

Place: Madhepura 2. RITIK (21105128046)
3. ANUSHKA SAUMYA (21105128024)

5
 ABSTRACT

This project report presents the development of an end-to-end automated stock reporting system,
designed to streamline the generation and delivery of customized market reports for users based on
their preferences. The system is built around a modular three-pipeline architecture, each
addressing a key part of the data lifecycle—from user interaction and data fetching to analytics and
final report delivery.

The platform accepts user input (email, phone number, asset preferences) via a simple Flask-based
frontend, processes stock/crypto/mutual fund data using scheduled APIs, performs technical
analytics, and ultimately generates a comprehensive, stylized PDF report sent via email. All of this
occurs with minimal human intervention, enabling users—traders, investors, or analysts—to receive
timely and actionable insights directly in their inboxes.

Technologically, the system leverages GitHub Actions for scheduled task automation,
PostgreSQL on Render for backend database support, and multiple financial APIs for real-time
data ingestion. The second pipeline processes and visualizes asset trends using tools like Plotly,
Matplotlib, and custom-built logic for calculating indicators (e.g., moving averages, RSI). The final
pipeline handles the generation of PDFs using weasyprint, complete with visualizations,
personalized summaries, and final delivery via Gmail API email automation.

This report outlines the project’s motivation, the current gap in customizable market reporting, and
the benefits of a modular, automated approach. It discusses the challenges faced—such as secure
credential management, API handling, and rendering issues—as well as the methodologies used to
overcome them. Special emphasis is given to system architecture, deployment using Render, and
CI/CD pipelines configured via GitHub workflows.

Future iterations of the platform may include a video report generator and publisher pipeline
(under development), AI-driven stock recommendations, and a mobile app for real-time
notifications and interactive dashboards.

Overall, the system stands as a scalable, production-ready solution aimed at simplifying and
accelerating financial decision-making through automation and smart integration.

6
 Table of Contents

Chapter Section Title Details / Subsections

Chapter 1: Introduction 1.1 Background and Motivation - The Need for Automated
Financial Reporting- Challenges
of Manual Tracking
1.2 Problem Statement - Gaps in Existing Tools for
Personalised, Automated
Reports
1.3 Project Objectives - Key Goals of the AutoStocks
System
1.4 Scope of the Project - Core Features (Three
Pipelines)- Future
Considerations (Video Pipeline)
1.5 Overview of AutoStocks - The Three-Pipeline
Solution Architecture
1.6 Report Structure - Overview of chapters and flow
Chapter 2: Literature Review 2.1 Existing Tools - Commercial, Open-Source,
/ Related Work Portfolio Trackers
2.2 Technologies in Financial - Data Sourcing, Processing,
Automation Report Generation
2.3 Customization and - Why flexibility matters
Automation Value
2.4 AutoStocks' Contribution - Unique value and niche
Chapter 3: System Design and 3.1 System Architecture - Modular Components- High-
Architecture Level Diagram
3.2 Three-Pipeline Workflow - Pipeline 1: Onboarding &
Asset List- Pipeline 2: Data &
Analytics- Pipeline 3: PDF &
Email
3.3 Key Technologies Used - Backend: Python, Flask,
PostgreSQL- Frontend: HTML,
CSS, JS- APIs: Alpha Vantage,
CoinMarketCap- Automation:
GitHub Actions- Reporting:
Weasyprint/FPDF, Matplotlib
3.4 Data Flow - Input to Output mechanism
3.5 Security Considerations - Data protection and auth
Chapter 4: Pipeline 1 – UI and 4.1 Web Frontend - Subscription Form- Input
Data Management Validation
4.2 PostgreSQL Database - User and Asset Schema
4.3 Auto Asset List Updates - GitHub Actions Automation
4.4 Email Notifications - Welcome and confirmation
mails
5.1 API Integration - Stock, Crypto, Mutual Funds
 Chapter 5: Pipeline 2 – Data
Aggregation & Analytics
5.2 Data Cleaning - Handling missing/inconsistent
values
5.3 Financial Analytics - Returns, RSI, MACD, Moving
Averages
5.4 Visualizations - Charts via Matplotlib
5.5 Scheduling - Automated via GitHub
Actions
Chapter 6: Pipeline 3 – Report 6.1 PDF Design - Layout, Branding, Content
Generation & Delivery
6.2 PDF Generation - Weasyprint or FPDF
6.3 Email Delivery - Gmail SMTP Automation
6.4 Full Automation - Combined GitHub Actions
Flow
Chapter 7: Deployment and 7.1 Hosting - [Link] (Flask +
CI/CD PostgreSQL)
7.2 CI/CD - GitHub Actions Testing &
Deployment
7.3 Secrets Management - GitHub Secrets for Tokens
Chapter 8: Testing and 8.1 Testing Approach - Unit & Functional Tests
Validation
8.2 Test Cases - Core workflows
8.3 Test Results - Summary of outcomes
Chapter 9: Results and 9.1 Performance - System throughput
Discussion
9.2 Sample Report - Snapshot of output
9.3 User Feedback - If collected
Chapter 10: Conclusion and 10.1 Summary - Highlights of the project
Future Work
10.2 Challenges - Issues faced during
development
10.3 Future Work - User Management- Video
Automation (n8n)- Advanced
Analytics

8
 Introduction

In today’s fast-paced financial landscape, individual investors and enthusiasts often lack the time,
tools, or technical expertise to track and analyze market data across multiple asset classes like
stocks, cryptocurrencies, and mutual funds. Traditional platforms either provide generic dashboards,
require manual data collection, or are hidden behind expensive paywalls. To bridge this gap, we
developed a fully automated, customizable, and scalable web-based system that generates and
delivers personalized market intelligence reports directly to users’ inboxes.

This project introduces a three-pipeline architecture, each dedicated to a core responsibility: user
interaction, data aggregation and analytics, and report generation with automated delivery.
The entire flow is designed to be hands-free, requiring the user only to select the desired financial
assets once, after which the system continuously fetches live data, applies analytics, and delivers
insightful, chart-rich PDF reports daily or weekly.

Built using a range of technologies—Flask, PostgreSQL, GitHub Actions, Matplotlib, Plotly, API
integrations, weasyprint, and Render hosting—the system ensures not only data reliability and
report quality but also high automation through CI/CD and scheduling tools. The architecture is
modular, making it easy to expand with future capabilities like AI-based forecasting, auto-generated
videos, or voice assistant integration.

With a strong focus on usability, automation, and precision, this project offers an innovative
approach to democratizing financial insights. The following chapters delve into each component
in detail—from the user interface and backend processing logic to the report structure and
deployment pipeline—making this document a comprehensive guide to building end-to-end, real-
time market intelligence systems.
 AIM AND OBJECTIVE

AIM: -

● To develop a fully automated, end-to-end platform that allows users to receive

personalized and analytics-rich stock, crypto, and mutual fund reports via email
without requiring any technical intervention.
● To design a scalable architecture that seamlessly integrates user inputs, real-time
data collection, financial analysis, and report generation using modern web
technologies and DevOps automation tools.
● To ensure that even non-technical users can interact with the platform easily and
receive visually informative and timely reports tailored to their selected financial
assets.
● To reduce dependency on paid platforms or manual financial research by automating key
insights using APIs, technical indicators, and visualizations.
● To support and encourage consistent financial awareness and investment tracking through
regular, customizable report delivery schedules (daily, weekly, etc.).

OBJECTIVE:

 To create a user-friendly frontend for users to select their preferred stocks, cryptos, or mutual
funds and input contact details like email or phone number.

 To build backend pipelines capable of fetching and aggregating real-time data using reliable
APIs, and applying analytical techniques such as moving averages, RSI, and time-series
visualizations.

 To generate dynamic PDF reports using templated layouts enriched with charts, tables, and
summaries, and automate their delivery to users through email.

 To schedule and automate the complete workflow—from data fetching to report generation to
email delivery—using tools like GitHub Actions jobs.

 To ensure secure storage of user preferences and data using PostgreSQL hosted on Render, with
reliable authentication and backup mechanisms.

 To make the system extensible for future integration with modules like video generation, AI-
driven predictions, or voice-based insights.

 To ensure that the platform runs with minimal human supervision by incorporating fault
detection, error handling, and retry mechanisms in each pipeline.

 To maintain the open-source nature of the project and provide detailed documentation and
flowcharts so other developers or users can contribute or deploy their own version.

10
 TECH STACK WE USED
Python & Flask
Python serves as the core programming language for this project, handling the backend logic and
data processing tasks. Flask, a lightweight and flexible web framework, powers the user interface
and API endpoints. Flask's Jinja2 templating engine is used to render HTML pages, while
extensions like Flask-WTF are employed for secure form handling and CSRF protection.

HTML, CSS, and JavaScript

The frontend of the application is designed using HTML5 and CSS3 for structure and styling.
JavaScript is integrated for interactive elements and client-side validations. The layout is
optimized for responsiveness and usability, ensuring accessibility across devices.

[Link]
[Link] hosts the deployed Flask application and manages scheduled tasks using its built-in
cron job feature. The platform supports free-tier deployment and integrates well with continuous
delivery pipelines. Gunicorn is used as the WSGI server to run the Flask app in production.

PostgreSQL
PostgreSQL is used as the primary relational database to store user data and analytics. It runs on
Render’s managed PostgreSQL service. Database connectivity is managed using psycopg2 or
SQLAlchemy, with configuration handled securely via environment variables.

GitHub Actions (CI/CD)

GitHub Actions is used to automate deployment workflows and scheduled tasks. The CI/CD
pipelines, defined in YAML files under .github/workflows, handle testing, deployment, and
execution of weekly data pipelines. Secrets are securely managed and redacted from logs.

Financial APIs and Libraries

APIs like Alpha Vantage, Yahoo Finance (via yahooquery), and CoinMarketCap are used to
fetch financial data such as stock, crypto, forex, and mutual fund prices. Python libraries like
requests and pandas facilitate API calls and data processing.

Data Processing & Analysis

Pandas is used extensively for handling and analyzing tabular data. The ta library (Technical
Analysis) adds over 130 indicators for feature extraction. Libraries like NumPy and SciPy
support numerical computations and statistical operations.

Visualization
Matplotlib and Plotly are used to create dynamic charts and graphs that visualize financial trends.
These visual assets are saved as image files and embedded within the final PDF reports.

PDF Generation
PDF reports are generated using libraries such as weasyprint or FPDF. HTML CSS supports
complex and customizable layouts, while FPDF offers simpler integration through its HTML
mix-in. These reports contain a mix of visual charts and analytical summaries.

Email Sending
Python’s smtplib and Gmail API is used to automate the delivery of weekly PDF reports via
email. When using Gmail API, secure OAuth credentials are stored and managed according to
best practices.

11
 Chapter 1: Introduction

1.1. Background and Motivation

In today's fast-paced financial markets, staying informed is critical for investors. The proliferation
of investment options, including traditional stocks, cryptocurrencies, and mutual funds, presents
both opportunities and challenges. Manually tracking these diverse assets, sourcing data from
numerous platforms, and compiling meaningful reports is a significant burden.
 The Need for Automated Financial Reporting:
The sheer volume and velocity of financial data necessitate automated solutions. Investors
and analysts increasingly rely on streamlined pipelines to extract insights from diverse
sources. Automation can save considerable time, reduce the likelihood of human error, and
provide timely updates crucial for informed decision-making.
 Challenges of Manual Tracking:
Manual tracking of financial assets is inherently "labor-intensive and error-prone"
(AutoStocks). This process often involves repetitive tasks like data collection from multiple
websites, spreadsheet management, manual calculation of metrics, and report formatting.
Such an approach is not scalable and can lead to outdated or inaccurate information,
potentially impacting investment strategies.

1.2. Problem Statement

While various financial tools and platforms exist, there is a clear gap in the market for a
comprehensive, end-to-end automated system that caters specifically to individual investors seeking
personalized reports on their selected assets.
 Gaps in Existing Tools for Personalised, Automated Reports:
Many investors require regular summaries of their portfolio performance, encompassing a
mix of stocks, cryptocurrencies, and mutual funds. Generating these reports involves
repetitive tasks: fetching price histories, computing metrics, creating charts, and distributing
results. Existing solutions often provide generic market data or limited portfolio tracking
without fully automated, scheduled report delivery tailored to a user's specific asset list. The
problem is "compounded by the variety of assets... and the need to deliver reports on a
schedule" .

1.3. Project Objectives

The AutoStocks project aims to develop a robust and user-friendly system to automate the
generation and delivery of personalized financial reports.
 Key Goals of the AutoStocks System:
The main objectives, as outlined in the OCR (p.1), are to:
1. Automate data collection: Fetch historical and real-time data for user-selected stocks,
cryptocurrencies, and mutual funds via public APIs.
2. Perform financial analytics: Compute key indicators and performance metrics
(returns, moving averages, RSI, etc.).
3. Generate reports: Assemble the analysis into a structured PDF report, including text
summaries and charts.
4. Automate email delivery: Distribute the PDF report to the user's email address.
5. Provide a user interface: Offer a simple web UI for users to submit their preferences
and manage subscriptions.
6. Ensure reliability and security: Design robust and secure data pipelines.
7. Implement continuous integration/continuous deployment (CI/CD): Allow for
seamless updates and deployments.
1.4. Scope of the Project
This project focuses on delivering a functional and deployable version of the AutoStocks system
with three core integrated pipelines.
 Core Features (Three Pipelines):
1. Pipeline 1 (UI & Capture): A web interface for user data capture (email, asset
selection) and database storage. This includes background tasks for updating
available asset lists.
2. Pipeline 2 (Aggregation & Analytics): An engine that periodically fetches market
data for user-selected assets, cleans and processes it, and computes financial
indicators.
3. Pipeline 3 (Reporting & Delivery): A system that compiles the analyzed data into a
formatted PDF report and emails it to the user on a schedule (e.g., weekly).
 Future Considerations (Video Pipeline):
While not part of the initial core delivery, a future pipeline is envisioned for generating
automated video content (e.g., YouTube Shorts, Instagram Reels). This pipeline would
leverage tools like n8n to create short video summaries of market insights and promote the
AutoStocks service, aiming for broader user reach and engagement.

1.5. Overview of the AutoStocks Solution

The AutoStocks system is designed as an automated financial reporting service that delivers
customized portfolio analysis directly to users, eliminating the need for manual effort.
 The Three-Pipeline Architecture:
The system is architected as a "three-pipeline workflow (UI & capture, analytics, reporting)
working in concert".
o Pipeline 1 (Capture & Setup): A Flask-based web application handles user input
(email, asset choices) and stores this information in a PostgreSQL database. GitHub
Actions will be used to periodically update the master list of available financial
assets (stocks, crypto, mutual funds) that users can select from.
o Pipeline 2 (Aggregation & Analytics): Scheduled jobs (via GitHub Actions or
Render Cron) retrieve user preferences and asset lists. It then calls external financial
data APIs (e.g., Alpha Vantage, CoinMarketCap, Yahoo Finance) to fetch price
histories, performs data cleaning, and computes key analytics and technical
indicators using Python libraries like Pandas and ta.
o Pipeline 3 (Reporting & Delivery): Another scheduled process takes the analytical
results from Pipeline 2, populates a pre-designed PDF report template (using
Weasyprint or FPDF) with text summaries and charts, and then emails the PDF as an
attachment to the subscribed user via Gmail SMTP.

1.6. Report Structure

This report details the design, implementation, and deployment of the AutoStocks system. Chapter 2
reviews related literature and existing systems. Chapter 3 outlines the system architecture and
technology stack. Chapters 4, 5, and 6 delve into the specifics of Pipeline 1, Pipeline 2, and Pipeline
3, respectively. Chapter 7 discusses deployment and CI/CD. Chapter 8 covers testing and validation.
Chapter 9 presents the results and discussion. Finally, Chapter 10 concludes the report and outlines
future work, including the planned video generation pipeline.
 Chapter 2: Literature Review / Related Work

The development of the AutoStocks system is informed by existing solutions and technologies in
the domain of financial data analysis and automated reporting. This chapter reviews relevant
systems and the technological landscape, highlighting the niche AutoStocks aims to fill.

2.1. Existing Financial Reporting Tools and Systems

A variety of tools exist for financial reporting and portfolio tracking, each with its strengths and
limitations when considered for personalized, automated retail investor reports.

 Commercial Solutions (e.g., Bloomberg Terminal, Refinitiv Eikon):

These platforms are powerful, offering comprehensive real-time data, advanced analytics,
and sophisticated reporting capabilities. However, they are primarily designed for
institutional investors and financial professionals. Their high cost makes them
inaccessible to the average retail investor, and they often lack the simplicity and direct
email-based reporting desired for personal use.

 Open-Source and Community Projects (e.g., hgnx/automated-market-

report, gsampallo/automated_report_python):
Several open-source projects demonstrate the feasibility of automating aspects of
financial reporting using Python. For instance, the "Automated Stock Market Report
Generator by hgnx" showcases fetching data from multiple sources (Yahoo Finance,
FRED, CNN) and compiling a daily PDF report. These projects often focus on general
market summaries rather than personalized portfolio reports, or they might "require
manual triggers" rather than being fully automated end-to-end user-driven services.
AutoStocks builds upon similar techniques (API usage, PDF generation) but aims for a
more complete, user-initiated, and personalized pipeline.

 Online Portfolio Tracking Services (e.g., Yahoo Finance, Google Finance):

Platforms like Yahoo Finance and Google Finance provide robust portfolio tracking
features, allowing users to monitor their investments. They offer charts, news, and basic
analytics. However, they generally "have limited analytics and no automatic email
reports" (AutoStocks OCR, p.3) in the customized, scheduled PDF format that
AutoStocks intends to provide. While users can view their portfolio online, the proactive
delivery of a consolidated, analytical report to their inbox is often missing.

2.2. Technologies in Financial Automation

The automation of financial reporting leverages a mature ecosystem of tools and programming
libraries, particularly within Python.

 Data Sourcing: APIs vs. Web Scraping:

Accessing financial data is fundamental. Public APIs from providers like Alpha Vantage
(for stocks, crypto, funds), CoinMarketCap (for crypto), and unofficial wrappers for
services like Yahoo Finance (e.g., yahooquery) are preferred due to their structured data
and reliability compared to web scraping, which can be fragile and legally ambiguous.
AutoStocks relies on such APIs for robust data collection.
  Data Processing and Analysis Libraries (Python ecosystem):
Python, with libraries such as Pandas for data manipulation, NumPy for numerical
operations, and specialized libraries like ta (Technical Analysis Library) for calculating
financial indicators (e.g., RSI, MACD, Moving Averages), forms the backbone of many
financial data projects. These tools enable efficient "computation of key indicators and
performance metrics".

 Report Generation Tools:

Libraries like Weasyprint and FPDF in Python facilitate the programmatic creation of
PDF documents. They allow for the structured assembly of text, tables, and embedded
images (charts), which is crucial for "generating a structured PDF report, including text
summaries and charts”.

 ETL (Extract, Transform, Load) Pipelines in FinTech:

While AutoStocks might not implement a full-scale traditional ETL system, the
principles are relevant. The process of extracting data from APIs, transforming it
(cleaning, calculating analytics), and loading it (into a PDF report or database) mirrors
ETL workflows commonly used in FinTech for processing financial data. Concepts like
"data pipeline best practices (logging, error handling, monitoring)" are applicable.

2.3. The Value of Customization and Automation

A key differentiator for AutoStocks is its focus on customization and full automation, addressing
a common pain point for individual investors.

 Off-the-shelf solutions and generic market reports "rarely allow fully customized
portfolios and automated distribution" Investors often have unique combinations of assets
and prefer reports tailored to their holdings and delivered on their schedule.

 "Customization is crucial: users should receive only the metrics and charts relevant to
their selected assets". This personalized approach enhances the relevance and utility of
the reports.

 Automating the entire process, from data fetching to email delivery, saves users
significant time and effort, aligning with the trend where "automation allows for quick
and efficient scenario analysis" and routine tracking.

2.4. AutoStocks' Niche and Contribution

The literature and existing tool landscape reveal a strong interest in automating financial data
analysis. However, many solutions are either too broad, too expensive, not fully automated, or
lack deep personalization for individual retail investors.

 AutoStocks aims to fill this niche by providing an accessible, "completely end-to-end,

user-initiated pipeline".

 It combines user-friendly subscription, automated data aggregation from diverse asset

classes (stocks, crypto, and mutual funds), personalized analytics, and scheduled PDF
report delivery via email.

.
 Chapter 3: System Design and Architecture

The AutoStocks system is engineered with a modular architecture to ensure clarity,

maintainability, and scalability. This chapter details the overall system design, its core
components, the workflow of its distinct pipelines, and the key technologies employed.

3.1. Overall System Architecture

The AutoStocks system is organized as a multi-tier application, emphasizing a clear separation of

concerns between user interaction, data processing, and report delivery. This modular design
facilitates independent development, testing, and scaling of different parts of the system.

 Modular Design and Component Overview:

The architecture is built around three primary pipelines that work in concert, supported
by a central database and automation tools. The main components include:

o Web Frontend: The user-facing interface for subscription and asset selection.

o Database: Persistent storage for user profiles, asset selections, and potentially
cached data.

o Analytics Engine: Backend services responsible for data fetching, processing, and
financial calculations.

o Report Generator: A module dedicated to creating structured PDF reports.

o Notification Service: Handles email delivery of reports.

o Automation Orchestrator: Manages scheduled tasks and CI/CD workflows.

 High-Level System Diagram (Description):

(This section would typically contain a visual diagram. For this text-based report, the
diagram would depict the following flow):
A user interacts with the Web Frontend (Pipeline 1) to subscribe and select assets. This
information is stored in the Database. Periodically, a Scheduled Trigger (e.g., GitHub
Actions cron job) initiates Pipeline 2 (Analytics Engine). Pipeline 2 reads user data from
the Database, fetches financial data from external APIs, performs analytics, and generates
chart data. The results are then passed to Pipeline 3 (Report Generator), which creates a
PDF report. Finally, Pipeline 3 uses the Notification Service to email the PDF report to
the user. GitHub Actions also manage the deployment of the Web Frontend and the
scheduling of the backend pipelines.
3.2. The Three-Pipeline Workflow

The core functionality of AutoStocks is delivered through a three-pipeline workflow, ensuring a

logical progression from user input to report delivery.

 Pipeline 1: User Onboarding & Asset List Management:

This pipeline encompasses the user's initial interaction with the AutoStocks system.

1. User Interface (UI): A Flask-based web application presents an HTML form for
users to input their email address and select their desired financial assets (stocks,
cryptocurrencies, mutual funds).

2. Data Capture & Validation: User input is validated and then stored in a
PostgreSQL database.

3. Asset List Maintenance: A background process, managed by GitHub Actions,

periodically fetches and updates the master list of available stocks,
cryptocurrencies, and mutual funds, ensuring the user interface offers current
options.

 Pipeline 2: Data Aggregation & Financial Analytics:

This pipeline is the computational core of the system, responsible for gathering and
analyzing financial data.

1. Scheduled Trigger: A cron job (via GitHub Actions or Render Cron) initiates this
pipeline at regular intervals (e.g., weekly).

2. Data Retrieval: The system reads user preferences and selected asset lists from the
database. It then queries external financial APIs (Alpha Vantage, CoinMarketCap,
Yahoo Finance) to fetch historical and recent price data for these assets.

3. Data Processing & Analysis: The raw data undergoes cleaning (handling missing
values, aligning time series). Financial analytics are then computed, including
returns, moving averages, RSI, MACD, and other relevant technical indicators,
using Python libraries like Pandas and ta.

4. Visualization Preparation: Data for charts (e.g., price trends, indicator plots) is
prepared.

 Pipeline 3: PDF Report Generation & Email Delivery:

This final pipeline focuses on creating a tangible output and delivering it to the user.

1. Report Compilation: Using the analytics and chart data from Pipeline 2, a
structured PDF report is generated. This involves populating a pre-designed
template with text summaries, tables of metrics, and embedded charts.

2. Emailing: The generated PDF report is attached to an email and sent to the user's
registered email address using Gmail SMTP.
This pipeline is triggered automatically after the completion of Pipeline 2
analytics.
3.3. Key Technologies Used

The AutoStocks system leverages a combination of open-source tools and cloud services to
deliver its functionality.

 Backend:

o Python 3.x: The primary programming language for all backend logic, chosen for
its extensive libraries and suitability for data analysis and web development.

o Flask: A lightweight Python web framework used to build the user interface and
API endpoints for Pipeline 1.

o PostgreSQL: A robust open-source relational database used for storing user

information, asset selections, and potentially intermediate data. Hosted on
[Link].

 Frontend:

o HTML5, CSS3, JavaScript: Standard web technologies for structuring, styling,

and adding interactivity to the user subscription form.

 Data APIs:

o Alpha Vantage: For stock, cryptocurrency, and mutual fund data.

o CoinMarketCap: For detailed cryptocurrency market data.

o Yahoo Finance (via yahooquery library): As an alternative or supplement for

stock and fund data.

 Data Processing & Analysis:

o Pandas: For data manipulation and analysis, particularly with time-series data.

o NumPy: For numerical computations.

o ta (Technical Analysis Library): For calculating a wide range of technical

indicators.

 Reporting & Visualization:

o Weasyprint (or FPDF): Python libraries for programmatic PDF generation.

o Matplotlib (or Plotly): For creating static charts and graphs to be embedded in the
PDF reports.
  Automation & Deployment:

o GitHub Actions: For CI/CD (automating testing and deployment to Render) and
for scheduling the execution of Pipeline 2 and Pipeline 3 (data aggregation,
analytics, report generation, and emailing).

o [Link]: The cloud platform for hosting the Flask web application and the
PostgreSQL database.

 Emailing:

o smtplib (Python standard library) / Gmail API: For sending emails with PDF
attachments.

3.4. Data Flow and Management

Data integrity and efficient flow are crucial.

1. Ingestion: User data (email, asset choices) is ingested via the Flask web form. Financial
market data is ingested from external APIs. Updated asset lists are ingested by a
scheduled script.

2. Storage: User subscription data and selected assets are stored persistently in the
PostgreSQL database. Fetched market data might be temporarily stored or processed in
memory during pipeline execution.

3. Transformation: Raw market data is cleaned, aligned, and transformed into calculated
metrics and indicators.

4. Output: The primary output is the personalized PDF report, delivered via email. Logs are
generated for monitoring.

3.5. Security Considerations

Security is a key aspect of the system design:

 Secrets Management: API keys, database credentials, and email service passwords are
managed securely using GitHub Secrets for automation workflows and environment
variables on Render for the deployed application. They are not hardcoded.

 HTTPS: The web application deployed on Render runs over HTTPS, encrypting data in
transit between the user and the server.

 Input Validation: User inputs (email format, asset tickers) are validated on both client and
server sides to prevent common injection vulnerabilities and ensure data integrity.

 Database Security: Render's managed PostgreSQL service provides a secure

environment, and connections are typically made over private networks within Render.
Workflow 1: Website and User Interaction

 Built using HTML/CSS/JS and Flask as the backend framework.

 Integrated with GitHub Actions for CI/CD automation and SMTP email system for user
communication.
 Collects user data from the website, stores it in the database, and triggers other workflows
as needed.

Workflow 2: Data Processing and PDF Generation

 Periodically fetches data from the server/database.

 Applies Python-based ML models, data analytics, and API integration.
 Uses LLM (Large Language Model) to generate intelligent content.
 Produces a personalized PDF report, which is then emailed to the user.

Workflow 3: Video Content Creation for Promotion

 Reuses data to fetch topic-related information.

 Automates video creation, then uploads to YouTube and Instagram.
 Leverages shorts for audience engagement and driving traffic back to the website.
Chapter 4: Pipeline 1 – User Interface, Data Management, and Notifications

Pipeline 1 forms the initial touchpoint for users with the AutoStocks system. It is responsible for
capturing user preferences, managing their data securely, handling initial notifications, and
ensuring the system has an up-to-date list of available financial assets for users to choose from.

4.1. Web Frontend (Flask Application)

The user-facing component of Pipeline 1 is a web application built using the Flask
microframework in Python. Its primary purpose is to provide a simple and intuitive interface for
users to subscribe to the AutoStocks service.

 User Subscription Form:

The core of the web frontend is an HTML form. This form is designed to collect:

o User's Email Address: The primary identifier for the user and the destination for
the weekly reports.

o Asset Selections: Users can select the stocks, cryptocurrencies, and mutual funds
they wish to track. This is implemented using a multi-select dropdown or a series
of checkboxes, populated dynamically with available assets.

o (Optional) Phone Number: This field might be included for future notification
features but is not essential for the core email reporting service.

The form is styled using HTML5 and CSS3 (potentially with a framework like Bootstrap for
responsiveness) to ensure a clean layout and usability across different devices. Minimal
JavaScript is used for client-side validation (e.g., checking email format) and enhancing user
experience (e.g., dynamic search within asset selection).

 Input Validation and Processing:

Upon form submission (via a POST request), Flask routes handle the incoming data.

1. Server-Side Validation: Robust validation is performed on the server to ensure data

integrity. This includes verifying the email format, checking that at least one asset has been
selected, and potentially validating ticker symbols against the master list.

2. Data Sanitization: Inputs are sanitized to prevent common web vulnerabilities.

Flask's Jinja2 templating engine is used to render the HTML form dynamically, including
populating the asset selection options and displaying any validation error messages to the user.

4.2. Database (PostgreSQL on Render)

User subscription data and asset preferences are stored persistently in a PostgreSQL database,
hosted as a managed service on [Link].

 Schema for User and Asset Data:

A simple yet effective database schema is employed. A primary users (or subscriptions)
table stores:
 o id: A unique auto-incrementing primary key.

o email: The user's email address (VARCHAR, NOT NULL, UNIQUE).

o phone_number: (VARCHAR, optional).

o selected_assets: A text field storing a comma-separated list or JSON array of the

asset tickers/symbols selected by the user (TEXT, NOT NULL).

o report_frequency: (VARCHAR, e.g., 'weekly', with a default value).

An assets_master_list table might also exist to store all available tickers and their types (stock,
crypto, mutual fund), which is used to populate the selection form and validate user choices.

 Data Persistence:
The Flask application interacts with the PostgreSQL database using a Python library
like psycopg2 (for direct SQL execution) or an ORM like SQLAlchemy (for a more
abstracted approach). Upon successful form validation, a new record is inserted into
the users table. Database connection details (host, port, username, password, database
name) are securely managed as environment variables on Render.

4.3. Automated Asset List Updates (GitHub Actions)

To ensure that users can select from a current list of financial instruments, a background process
regularly updates the master list of available stocks, cryptocurrencies, and mutual funds.

 Rationale and Process:

Financial markets are dynamic; new stocks are listed, cryptocurrencies emerge, and
mutual fund offerings change. Manually updating the list of selectable assets would be
inefficient.
Therefore, a Python script (e.g., update_asset_list.py) is developed. This script:

1. Fetches lists of popular or all available assets from reliable sources or APIs (e.g.,
exchange listings, financial data providers).

2. Processes and formats this data.

3. Updates the assets_master_list table in the PostgreSQL database or updates a flat

file (e.g., JSON or CSV) within the project repository that the Flask app reads
from.

 Scheduling with GitHub Actions:

A GitHub Actions workflow is configured with a cron schedule (e.g., bi-weekly or
monthly) to automatically execute this update_asset_list.py script. This ensures the asset
options presented to new users are reasonably up-to-date without manual intervention.
Secrets required by this script (e.g., API keys for fetching asset lists) are stored as GitHub
Secrets.
4.4. Initial User Notifications (Email)

Upon successful subscription, an immediate confirmation email is sent to the user.

 Confirmation Message:
This email serves to:

o Confirm successful registration for the AutoStocks service.

o Reiterate the email address provided and potentially the selected assets.

o Inform the user about the reporting schedule (e.g., "You will receive your first
weekly report next Sunday.").

 Email Sending Mechanism:

The Flask application, after successfully writing the user's data to the database, triggers
an email sending function. This function uses Python's smtplib library or the Gmail API
(with OAuth 2.0 for better security if feasible) to connect to Gmail's SMTP server and
send the confirmation email. Credentials for the email service are stored securely as
environment variables. Error handling is implemented to log any failures in sending the
confirmation email, though this typically would not prevent the subscription itself from
being recorded.

This pipeline ensures a smooth onboarding experience and lays the foundation for the subsequent
automated reporting pipelines by capturing essential user data and preferences.

Website Workflow Explanation

This workflow illustrates the functioning of the website system, which includes both frontend and
backend components, integrated with automation and communication tools.

1. Frontend:
The user interacts with the website built using HTML, CSS, and JavaScript, providing a
responsive and interactive UI.
2. Backend:
The backend is powered by Flask, which handles routing, logic, and communication
between frontend and the server.
3. GitHub Actions:
Used for automating updates and deployment, ensuring the website content remains current
without manual intervention.
4. SMTP Email System:
When a user interacts (e.g., submits a form or request), an automatic email is triggered and
sent to the user using SMTP.
5. Database:
All user data is securely stored in a central database, which can later be accessed for
processing and generating reports or further actions.
Chapter 5: Pipeline 2 – Data Aggregation, Analytics, and Visualization

Pipeline 2 is the analytical heart of the AutoStocks system. Triggered on a schedule, it is

responsible for fetching fresh market data for user-selected assets, performing necessary cleaning
and transformations, computing a range of financial analytics and technical indicators, and
preparing data for visualizations to be included in the final report.

5.1. Financial Data API Integration

Reliable and timely financial data is the cornerstone of this pipeline. AutoStocks integrates with
several public APIs to source data for stocks, cryptocurrencies, and mutual funds.

 Fetching Data for Stocks, Crypto, Mutual Funds:

1. Alpha Vantage: This API is a primary source, offering free (with rate limits)
access to historical and real-time data for stocks (e.g., TIME_SERIES_DAILY),
cryptocurrencies (Digital & Crypto Currencies endpoints), and even some mutual
fund NAVs. An API key is required and managed securely.

2. CoinMarketCap: For more detailed cryptocurrency data, including prices, market

capitalization, and trading volumes for a vast number of coins, the
CoinMarketCap API is utilized. This also requires an API key.

3. Yahoo Finance (via yahooquery or similar libraries): The yahooquery Python

library provides a convenient wrapper to access data from Yahoo Finance, which
is a rich source for stock quotes, historical prices, and mutual fund NAVs (often
identified with suffixes like .NS for Indian markets or .FUND for others).

The system queries these APIs based on the asset tickers/symbols selected by each subscribed
user, as retrieved from the PostgreSQL database. Python's requests library or specific client
libraries for these APIs are used for making HTTP requests. Careful management of API keys
and adherence to rate limits (e.g., by introducing small delays between calls if necessary) are
crucial for sustained operation. Error handling is implemented to gracefully manage API
unavailability or invalid ticker responses.

5.2. Data Processing and Cleaning

Raw data obtained from APIs often requires preprocessing and cleaning before it can be used for
analysis. This stage ensures data quality and consistency.

 Handling Missing Values: Financial data can have gaps due to market holidays (for
stocks and mutual funds), delisted assets, or API inconsistencies. Small gaps in time
series data (e.g., a single missing day's NAV for a mutual fund due to a bank holiday) are
handled using techniques like forward-fill (ffill) or backward-fill (bfill) in Pandas. If
significant data is missing for an asset, it might be excluded from that week's report for
that user, with a note.

 Date Alignment and Timezone Management: When dealing with multiple assets,
especially across different classes (e.g., stocks trading on specific exchange hours vs.
24/7 crypto markets), it's important to align data on a common date index. All timestamps
are typically converted to a uniform timezone (e.g., UTC) for consistency.
  Data Type Conversions: Price data is ensured to be in numeric (float) format for
calculations. Dates are parsed into datetime objects.

 Outlier Detection (Basic): Spurious spikes or drops in data might indicate errors. Basic
checks (e.g., unusually large day-over-day percentage changes) can be implemented, and
such data points might be flagged or smoothed, though complex outlier removal is
beyond the initial scope.
All cleaned data is typically loaded into Pandas DataFrames for efficient manipulation
and analysis.

5.3. Core Financial Analytics

Once the data is clean, various financial metrics and technical indicators are computed for each
asset.

 Returns:

o Daily Returns: Calculated as price.pct_change().

o Cumulative Returns: Calculated over the reporting period (e.g., weekly)

using (daily_return + 1).cumprod() - 1.

o Overall Period Return: (End Price / Start Price) - 1 for the week.

 Moving Averages (MA):

o Simple Moving Averages (SMA): E.g., 50-day and 200-day SMAs (or shorter
periods like 10-day, 20-day for weekly reports) are calculated
using [Link](window=N).mean().

o Exponential Moving Averages (EMA): Calculated

using [Link](span=N, adjust=False).mean().

 Key Technical Indicators (using the ta library):

o Relative Strength Index (RSI): A momentum oscillator measuring the speed and
change of price movements. Calculated using [Link].

o Moving Average Convergence Divergence (MACD): A trend-following

momentum indicator. Calculated using [Link].

o Bollinger Bands: Bands plotted two standard deviations away from a simple
moving average, indicating volatility. Calculated
using [Link].
Other indicators from the ta library can be added as needed. The results of these
computations are typically added as new columns to the Pandas DataFrame for
each asset.
5.4. Generating Visualizations (Charts)

Visual representations of data and trends are key components of the financial report. Python
libraries like Matplotlib or Plotly are used to generate these charts, which are then saved as
image files (e.g., PNG) for embedding into the PDF.

 Types of Charts:

o Price/NAV Time Series Chart: Line chart showing the asset's price or NAV over
the reporting period (e.g., last 7 days, last 30 days), possibly with overlays like
moving averages.

o Indicator Charts: Separate plots below the price chart for indicators like RSI or
MACD.

o Returns Histogram: A histogram of daily or weekly returns to illustrate

distribution and volatility.

o (Portfolio-level, if implemented): A cumulative return chart for the user's overall

selected assets (if a portfolio view is constructed).
Charts are titled appropriately and include legends where necessary.

5.5. Scheduling with GitHub Actions

The entire Pipeline 2 workflow—from fetching user data to computing analytics and generating
chart images—is automated and scheduled.

 Cron Job: A GitHub Actions workflow is configured with a cron trigger to run at a
specific time each week (e.g., every Sunday morning).

 Workflow Execution: The workflow checks out the latest code, sets up the Python
environment, installs dependencies, and then executes the main Python script responsible
for Pipeline 2's operations. This script iterates through all subscribed users, processing
their selected assets.

 Output Handling: The computed analytics and paths to the saved chart image files are
stored, ready to be picked up by Pipeline 3 for report generation. This could be by writing
to a temporary structured file (JSON), updating specific fields in the database, or passing
data directly if Pipeline 2 and 3 run in the same workflow execution.

Error handling throughout this pipeline is critical. Failures in fetching data for one asset should
not stop the processing for other assets or other users. Comprehensive logging captures the
progress and any issues encountered.
 Connect to Database: Establish a secure connection to the PostgreSQL database containing user
and asset data.

 Fetch User & Asset Data: Retrieve subscribed users and their chosen stock, crypto, or mutual
fund tickers.

 Fetch Financial Data: Pull historical prices, fundamentals, and news for each asset using APIs
like yfinance and GoogleNews.

 Analytics & ML Forecast: Clean data, calculate key metrics, and forecast short-term trends
using time-series models.

 LLM Summary: Use an LLM to convert raw data and forecasts into short, human-like insights
per asset.

 Generate Charts: Create visualizations such as price trends and technical indicators using
Matplotlib.

 Create PDF Report: Compile personalized financial reports with analytics, charts, news, and
summaries.

 Send Email: Email the generated PDF report to each user via Gmail SMTP.

 Automation & Orchestration: Automate the entire workflow weekly using GitHub Actions
with robust error handling.
 Chapter 6: Pipeline 3 – PDF Report Generation and Delivery

Pipeline 3 is the final stage in the AutoStocks workflow, responsible for transforming the
analyzed data and visualizations from Pipeline 2 into a professional, human-readable PDF report.
This report is then automatically delivered to the subscribed user's email inbox.

6.1. PDF Report Design

A well-designed report template is crucial for presenting financial insights effectively. The PDF
report aims to be concise, informative, and easy to understand.

 Structure and Content:

The report is structured with several key sections:

1. Header: Includes the "AutoStocks Weekly Report" title, the reporting period (e.g.,
"Week ending [Date]"), and the user's email address (for personalization). A
simple logo could also be included.

2. Overall Summary (Optional): A brief textual summary of the overall performance

of the selected assets for the week (e.g., "Your selected assets had an average
return of X% this week.").

3. Asset-Specific Sections: For each asset selected by the user:

 Asset Name/Ticker.

 Key Metrics Table: Start price, end price, percentage change for the week,
and perhaps key indicator values (e.g., current RSI, SMA values).

 Price/NAV Chart: The time-series chart generated in Pipeline 2.

 Indicator Charts (Optional): RSI/MACD charts below the main price

chart.

 Brief Textual Summary (Optional, if generated): A short sentence

highlighting a key observation (e.g., "AAPL closed the week up 2.5%.").

4. Returns Histogram (Optional): A chart showing the distribution of returns for one
or more key assets.

5. Footer: May include page numbers and a disclaimer (e.g., "Data for informational
purposes only.").

 Styling:
Consistent styling is applied using fonts (e.g., Helvetica, Arial), appropriate font sizes for
headings and body text, and clear color schemes for charts (ensuring readability). The
layout prioritizes clarity and professional presentation.
6.2. PDF Generation (Weasyprint/FPDF)

Python libraries are used to programmatically generate the PDF documents. Weasyprint is a
powerful choice for complex layouts, while FPDF can be simpler for more straightforward
designs.

 Library Choice: The selection between Weasyprint and FPDF depends on the desired
complexity and control over the PDF layout. Weasyprint offers more advanced features
with its "Platypus" high-level templating system, while FPDF is known for its ease of
use, especially if an HTML-like cell-based layout is sufficient.

 Embedding Text and Charts:

The chosen library's functions are used to:

o Add Text: Place headings, paragraphs of summary text, and table data onto the
PDF pages. Font styles, sizes, and alignments are controlled programmatically.

o Draw Tables: Create tables to display key metrics for each asset in an organized
manner.

o Insert Images: Embed the chart images (PNG files) generated in Pipeline 2 at
specific locations within the PDF document, ensuring appropriate scaling and
resolution.
The script iterates through each user's analyzed data and selected assets,
dynamically populating the PDF template. Each user receives a PDF tailored to
their specific subscriptions.

6.3. Automated Email Delivery

Once the personalized PDF report is generated, it is automatically emailed to the user.

 Constructing the Email:

Python's [Link] module is used to construct a multipart email message. This allows
for both a plain text or HTML body and file attachments.

o Recipient: The user's email address (retrieved from the database).

o Subject: A clear and informative subject line, e.g., "Your AutoStocks Weekly
Financial Report."

o Body: A brief polite message, e.g., "Dear User, please find your weekly
AutoStocks report attached."

 Attaching the PDF:

The generated PDF file is read in binary mode and attached to the email as
a MIMEApplication part with the Content-Type set to application/pdf and a Content-
Disposition header indicating it's an attachment with a filename
(e.g., AutoStocks_Report_[Date].pdf).
  Sending via Gmail SMTP:
Python's smtplib library is used to connect to Gmail's SMTP server ([Link] on
port 587 using TLS, or port 465 using SSL). The system logs in using pre-configured
email credentials (an app password for Gmail is recommended for security if not using
OAuth 2.0 with the Gmail API). The constructed email message is then sent to the user.
Secure storage of email credentials as environment variables is essential.

6.4. Workflow Automation

The generation and delivery of reports (Pipeline 3) are integrated into the automated weekly
schedule, typically following the completion of Pipeline 2.

 Triggering:
Pipeline 3 can be a subsequent step within the same GitHub Actions workflow that runs
Pipeline 2. Once analytics are complete and charts are saved, the PDF generation and
emailing scripts are executed for each user.

 Data Handoff:
The analytics results and paths to chart image files from Pipeline 2 are passed to the
Pipeline 3 scripts. This could be via temporary files, database entries, or in-memory data
structures if part of a single execution context.

 Error Handling:
Robust error handling is implemented. If PDF generation fails for a user (e.g., a missing
chart file), that user's report might be skipped for the week, and the error logged. If email
sending fails (e.g., SMTP server issue), the system might attempt a retry or log the failure
for administrator review. The failure of one user's report should not prevent others from
being processed and sent.

This pipeline ensures that users receive their personalized financial insights in a convenient and
professional format directly in their inbox, fulfilling the core promise of the AutoStocks system.
 Chapter 7: Deployment, Hosting, and CI/CD

A robust deployment strategy and continuous integration/continuous deployment (CI/CD)

pipeline are essential for the reliability, maintainability, and scalability of the AutoStocks
system. This chapter outlines how the application is hosted, how the database is managed, and
how GitHub Actions are utilized for automation.

7.1. Hosting on [Link]

[Link] is chosen as the Platform-as-a-Service (PaaS) provider for hosting the AutoStocks
web application and its associated database. Render simplifies infrastructure management,
allowing the focus to remain on application development.

 Deploying the Flask Application (Web Service):

The Flask application (Pipeline 1 UI) is deployed as a "Web Service" on Render.

1. Repository Connection: The Render service is linked directly to the GitHub

repository containing the AutoStocks codebase (e.g., singhsourav0/Stocks-
Services).

2. Build Command: Render automatically detects a Python project. The build

command is configured as pip install -r [Link] to install all necessary
Python dependencies listed in the [Link] file.

3. Start Command: The start command is set to gunicorn

app:app (where app:app refers to the Flask application instance within the main
application file, e.g., [Link]). Gunicorn is a production-ready WSGI HTTP server
for Python.

4. Environment Variables: Critical configuration details, such as database

connection strings, API keys for services used by the Flask app (if any directly),
and email credentials for confirmation emails, are set as environment variables
within the Render dashboard. This keeps sensitive information out of the
codebase.

5. Auto-Deploy: Render is configured to automatically build and deploy the

application whenever new changes are pushed to the connected GitHub
repository's main branch.
Render provides a public URL (e.g., [Link]) for the live web
service and handles HTTPS (SSL/TLS) termination automatically, ensuring
secure communication.

 PostgreSQL Database Hosting:

The PostgreSQL database is also hosted as a managed service on Render.

1. Instance Creation: A new PostgreSQL instance is created through the Render

dashboard.

2. Connection Details: Render provides connection details (host, port, database

 name, username, password) for the database. These are then configured as
environment variables for the Flask web service and any backend scripts (like
those in Pipeline 2 or 3 if they directly access the DB for user lists).

3. Private Networking: Render's services within the same account and region can
typically communicate over a private network, enhancing security and reducing
latency between the web application and the database.

4. Managed Service Benefits: Render handles database maintenance, backups

(point-in-time recovery often available on paid tiers), and scaling, reducing the
operational overhead.

7.2. GitHub Actions for CI/CD and Scheduled Tasks

GitHub Actions is the backbone of automation for AutoStocks, handling Continuous Integration,
Continuous Deployment, and the scheduling of backend data processing and reporting pipelines.

 Continuous Integration (CI):

For every push or pull request to the main development branches, a CI workflow is
triggered. This workflow typically includes:

o Checking out the code.

o Setting up the Python environment.

o Installing dependencies.

o Running linters (e.g., Flake8, Ruff) to check code style and quality.

o Running automated tests (e.g., using Pytest) to ensure code correctness and
prevent regressions.
If any of these steps fail, the CI build is marked as failed, alerting developers to
issues before they are merged or deployed.

 Continuous Deployment (CD):

Upon a successful merge to the main branch (and if CI tests pass), a CD workflow can
automatically trigger a deployment to Render. This can be achieved using Render's
deploy hooks or the render-deploy-action available on the GitHub Marketplace. This
ensures that the latest stable version of the application is always live.

 Scheduled Tasks (Pipelines 2 & 3 Automation):

Separate GitHub Actions workflows are defined with on: schedule (cron) triggers to run
Pipeline 2 (Data Aggregation & Analytics) and Pipeline 3 (Report Generation &
Delivery) at regular intervals (e.g., weekly). These workflows:

o Check out the relevant code.

o Set up Python and install dependencies.

o Execute the Python scripts responsible for fetching data, performing analytics,
generating PDFs, and sending emails.

o Utilize GitHub Secrets for API keys and other sensitive credentials needed by
 these backend scripts.

7.3. Secrets Management

Securely managing sensitive information is paramount.

 GitHub Secrets: API keys for financial data services (Alpha Vantage, CoinMarketCap),
email credentials (if used by scheduled tasks), and the Render API key (for CD) are
stored as encrypted secrets in the GitHub repository settings. GitHub Actions workflows
can securely access these secrets at runtime, and they are automatically redacted from
logs.

 Render Environment Variables: Database credentials, email credentials (for the Flask
app's confirmation emails), and any other runtime secrets for the live application are
stored as environment variables in the Render dashboard for the Web Service and any
Cron Jobs run on Render.

This comprehensive approach to deployment and automation ensures that the AutoStocks system
is not only functional but also maintainable, scalable, and can be updated efficiently with
minimal manual intervention.
 Chapter 8: Testing and Validation

Thorough testing and validation are crucial to ensure the AutoStocks system functions correctly,
reliably, and securely. This chapter outlines the testing strategy, types of tests conducted, and the
process for validating the system's outputs.

8.1. Testing Approach

A multi-faceted testing approach is adopted, combining automated tests for core functionalities
and regression prevention with manual checks for user experience and end-to-end validation.
The primary tool for automated testing in Python is Pytest.

 Automated Testing (Pytest):

Unit tests and integration tests are written to cover critical components of the system.
These tests are integrated into the CI/CD pipeline (GitHub Actions) and run
automatically on every code change.

 Functional Testing:
Ensures that each feature of the application works as intended from the user's perspective
or as per its defined role in the pipeline.

 Manual User Testing (UAT):

Involves interacting with the system as an end-user would, to identify usability issues and
verify the overall workflow.

 Error and Edge Case Handling:

Specific tests are designed to check how the system behaves under error conditions or
with unusual inputs.

8.2. Key Test Cases and Scenarios

A variety of test cases are designed to cover the different aspects of the AutoStocks system:

 Pipeline 1: User Interface and Data Management

o Form Submission Tests (Flask Test Client):

 TC1.1 (Valid Signup): Simulate submitting the signup form with valid
email and asset selections. Verify that a new user record is created in the
database and a confirmation email (mocked or sent to a test inbox) is
triggered.

 TC1.2 (Invalid Email): Submit the form with an improperly formatted

email. Verify that an appropriate error message is displayed and no
database entry is made.
  TC1.3 (No Assets Selected): Submit the form without selecting any assets.
Verify error handling.

 TC1.4 (Asset List Update): Test the script that updates the master asset
list, ensuring it fetches and stores data correctly (can be tested in
isolation).

 Pipeline 2: Data Aggregation and Analytics

o API Data Fetch Tests:

 TC2.1 (Valid Ticker): Test the data fetching function for a known valid
stock, crypto, or mutual fund ticker. Verify that data is returned in the
expected format. (May involve mocking API responses to make tests
deterministic and avoid actual API calls during CI).

 TC2.2 (Invalid Ticker): Test with an invalid ticker. Verify graceful error
handling (e.g., logging the error, skipping the asset).

 TC2.3 (API Rate Limit/Error): Simulate an API error or rate limit. Verify
that the system handles this (e.g., retries, logs, continues with other
assets).

o Analytics Computation Tests:

 TC2.4 (Returns Calculation): Provide a small, synthetic DataFrame of

prices. Verify that daily and cumulative returns are calculated correctly.

 TC2.5 (Indicator Calculation - e.g., RSI): Provide sample price data and
verify that the calculated RSI matches a manually computed or known
reference value.

o Chart Generation Tests:

 TC2.6 (Chart File Creation): Run the chart generation logic for sample
data. Verify that an image file (e.g., PNG) is created and is not empty.
(Deep inspection of chart content is harder to automate fully but file
existence is a good start).

 Pipeline 3: Report Generation and Delivery

o PDF Generation Tests:

 TC3.1 (PDF Creation): Run the PDF generation script with sample
analytics data. Verify that a PDF file is produced.

 TC3.2 (PDF Content (Basic)): Programmatically check (e.g., using

PyPDF2) if the generated PDF contains expected text elements like the
report title or a user's email.
Email Sending Tests:

 TC3.3 (Email with Attachment): Test the email sending routine. Verify
that an email is sent to a test inbox with the correct subject and a PDF
attachment. (Often involves mocking the smtplib interaction during
automated tests).

 End-to-End Workflow Tests (Integration/Manual):

o TC4.1 (Full Weekly Cycle): Manually subscribe with a test email and a set of
assets. Trigger the weekly pipeline (or wait for its scheduled run). Verify that a
PDF report is received via email and that its content accurately reflects the
selected assets and recent market data.

o TC4.2 (Error Resilience): Intentionally introduce an error (e.g., make one API key
invalid). Observe if the system logs the error correctly, skips the problematic part,
and continues processing for other users or assets where possible.

8.3. Results of Testing

 Automated Tests: The automated test suite (run via Pytest in GitHub Actions) aims for
high code coverage of critical modules. Passing tests provide confidence that core logic
functions as expected and that new changes do not introduce regressions. Test results
(pass/fail, coverage reports) are reviewed as part of the development cycle.

 Manual Validation: Manual end-to-end tests confirm the usability of the signup process
and the accuracy and presentation quality of the final PDF reports. Feedback from any
pilot users is also incorporated.

 Issue Tracking: Any bugs or issues identified during testing are logged, prioritized, and
addressed.

By combining these testing methodologies, the AutoStocks system is validated to meet its
functional requirements and maintain a high level of quality and reliability.
 Chapter 9: Results and Discussion

This chapter presents the outcomes of the AutoStocks project, discussing the performance of the
developed system, the nature of the reports generated, and any feedback received. It reflects on
the successful implementation of the core functionalities outlined in the project objectives.

9.1. System Performance Overview

The AutoStocks system, with its three-pipeline architecture, was developed and deployed
successfully. Performance benchmarks for a typical user scenario (e.g., tracking 5-10 assets)
indicate efficient operation:

 Pipeline 1 (User Onboarding):

o Webpage load times for the subscription form are minimal, ensuring a responsive
user experience.

o Form submission and database write operations are typically completed within a
few seconds.

o Automated asset list updates (run less frequently) depend on the number of assets
being fetched but are designed to run as background tasks without impacting user-
facing services.

 Pipeline 2 (Data Aggregation & Analytics):

o Data Fetch: For a portfolio of 5-10 assets, fetching data from APIs (Alpha
Vantage, CoinMarketCap, Yahoo Finance) generally takes between 5 to 20
seconds, depending on API response times and any necessary rate-limiting
pauses.

o Analytics Computation: Calculating returns, moving averages, and technical

indicators (RSI, MACD) using Pandas and ta for this dataset is very fast, typically
under 1-2 seconds.

o Chart Generation: Generating 5-10 Matplotlib charts and saving them as PNGs
takes approximately 2-5 seconds.

 Pipeline 3 (Report Generation & Delivery):

o PDF Generation: Assembling a multi-page PDF report (e.g., 3-5 pages) with text
and embedded charts using ReportLab/FPDF is efficient, usually taking 1-3
seconds.

o Email Send: Connecting to Gmail SMTP and sending an email with the PDF
attachment typically takes 2-5 seconds.
  Overall Weekly Pipeline Execution Time:
For a single user with a typical portfolio, the entire automated weekly pipeline (Pipelines
2 and 3) completes in well under a minute (often 15-30 seconds). The system is designed
to process users sequentially in the current iteration. For a larger number of users, the
total execution time would scale linearly, but individual report generation remains
efficient. The free-tier API rate limits are the primary constraint on processing a very
large number of unique assets rapidly.

These benchmarks demonstrate that the system is efficient for its intended use case of providing
weekly reports to individual users.

9.2. Sample Report Walkthrough

The generated PDF reports successfully deliver personalized financial insights as intended.

 User Input Example: Email: [Link]@[Link]; Assets: AAPL (Apple stock),

BTC (Bitcoin), [Link] (HDFC Bank mutual fund).

 Generated Report Content:

o Header: "AutoStocks Weekly Report for [Link]@[Link]," with the

relevant week-ending date.

o Asset Sections:

 AAPL: A table showing start/end price, weekly % change. A price chart

for AAPL for the past week (or month), potentially with an RSI chart
below it.

 BTC: Similar table and price chart for Bitcoin.

 [Link]: Similar table and NAV chart for the HDFC mutual fund.

o Formatting: The PDF is well-formatted with clear headings, readable fonts, and
legible charts. The information is presented concisely.

o Email Delivery: The report is received as a PDF attachment to an email with a

subject like "Your AutoStocks Weekly Financial Report."

The output aligns with the project's goal of delivering customized, automated financial
summaries. (Placeholders for screenshots of a sample email and PDF page would be referenced
here in a full report).
9.3. User Feedback (if available/applicable for a college project)

Initial informal feedback on the concept and sample reports has been positive, with users
appreciating:

 The convenience of receiving automated, personalized reports directly via email.

 The clarity of the charts and key metrics presented.

 The simplicity of the signup process.

Suggestions for future enhancements included the ability to modify asset lists post-subscription
via the UI and potentially adding brief news summaries relevant to the selected assets (though
news integration was out of the initial scope). No major functional issues were reported in the
core report generation and delivery mechanism during preliminary testing.

9.4. Discussion

The AutoStocks system successfully demonstrates the feasibility of creating a fully automated
pipeline for personalized financial reporting using readily available APIs, Python libraries, and
cloud hosting services. The modular three-pipeline architecture proved effective for organizing
the development and allows for future expansion. The use of GitHub Actions for CI/CD and task
scheduling significantly streamlines operations and maintenance.

While the current system is designed for individual retail investors and operates within the
constraints of free-tier APIs, the architecture provides a solid foundation for potential future
scaling and feature additions. The project effectively addresses the problem of manual, time-
consuming financial tracking by providing a "set-and-forget" solution for users.
 Chapter 10: Conclusion and Future Work

The AutoStocks project set out to address the need for automated, personalized financial
reporting for individual investors. This chapter summarizes the project's achievements, discusses
challenges encountered, and outlines exciting avenues for future development, including the
planned expansion into automated video content generation.

10.1. Summary of Achievements

The AutoStocks project successfully designed, developed, and deployed a three-pipeline

automated financial reporting system. Key achievements include:

 Fully Automated Workflow: An end-to-end system that allows users to subscribe with
their asset preferences and receive customized weekly PDF reports via email without
manual intervention.

 Multi-Asset Support: The system capably handles data aggregation and analysis for a
diverse range of assets, including stocks, cryptocurrencies, and mutual funds.

 Personalized Reporting: Reports are tailored to each user's specific asset selections,
providing relevant insights rather than generic market summaries.

 Robust Technology Stack: Effective use of Python, Flask, PostgreSQL, financial data
APIs (Alpha Vantage, CoinMarketCap, Yahoo Finance), ReportLab/FPDF, Matplotlib,
and cloud services ([Link]).

 CI/CD and Scheduled Automation: Implementation of GitHub Actions for continuous

integration, continuous deployment, and the scheduling of data processing and report
delivery pipelines.

 User-Friendly Interface: A simple web interface for user subscription, making the service
accessible.

The project has successfully met its primary objectives of automating data collection, performing
financial analytics, generating structured reports, and delivering them via email, all while
ensuring a degree of reliability and security.

10.2. Challenges Faced

Several challenges were encountered during the development process:

 API Limitations: Free-tier API rate limits required careful management and error
handling to ensure the system could operate without frequent interruptions, especially
when fetching data for multiple users or a large number of assets.

 Data Consistency Across APIs: Different APIs sometimes provide data in varying
formats or with different levels of granularity, necessitating robust data cleaning and
normalization steps.
  PDF Formatting Complexity: Achieving a polished and professional layout for PDF
reports, especially with dynamic content and embedded charts, using libraries like
ReportLab, involved a learning curve.

 Deployment and Configuration: Setting up environment variables correctly across

different environments (local development, GitHub Actions, [Link]) and debugging
initial deployment issues required meticulous attention to detail.

 Scope Management: Balancing the desire for extensive features with the practical
constraints of a project timeline required careful prioritization of core functionalities.

Overcoming these challenges provided valuable learning experiences in building and deploying
real-world data-driven applications.

10.3. Future Enhancements

The current AutoStocks system provides a solid foundation for numerous future enhancements
that could further increase its value and user base:

 Enhanced User Management:

o Allowing users to log in to update their asset list, change report frequency (e.g.,
daily, monthly), or unsubscribe via the web UI.

o Password reset and account management features.

 Expanded Data Sources and Analytics:

o Integrating news APIs (e.g., Bloomberg, Reuters via an API aggregator) to

include relevant headlines impacting a user's assets.

o Adding more advanced financial analytics, such as portfolio risk metrics (Sharpe
ratio, Value-at-Risk), correlation analysis, and fundamental data.

o Support for a wider range of international markets and asset classes.

 Interactive Reports:

o Exploring options for interactive HTML reports alongside or instead of PDFs,

perhaps using libraries like Plotly Dash or Bokeh.

 Mobile Application:

o Developing a companion mobile app (e.g., using React Native or Flutter) for
easier subscription, viewing reports, and receiving push notifications.

 AI/ML for Predictive Insights:

o Incorporating basic machine learning models (e.g., time-series forecasting like

ARIMA or simple regression) to provide potential future trend outlooks (clearly
marked as speculative).
 Pipeline for Automated Social Media Video Generation:
A significant planned future development is the creation of a fourth pipeline dedicated to
generating short-form video content for platforms like YouTube Shorts and Instagram
Reels.

o Rationale: To promote the AutoStocks service, increase visibility, attract new

users, and provide engaging, easily digestible market insights (e.g., daily Indian
stock market summaries).

o Conceptual Workflow:

1. Data Collection: Similar to Pipeline 2, fetch key market data (e.g., top
gainers/losers, index movements).

2. Content Scripting: Automatically generate a short script or key bullet

points for the video.

3. Visual Asset Generation: Create simple visual slides or animations (e.g.,

using Python libraries or integrating with tools that can be automated).

4. Text-to-Speech Narration: Use libraries like gTTS (Google Text-to-

Speech) or pyttsx3 to convert the script into an audio narration.

5. Video Compilation: Employ tools like MoviePy (Python library) to

combine visual assets, narration, background music (if any), and branding
into a short video (e.g., <60 seconds).

6. Orchestration with n8n: Utilize a workflow automation tool like n8n to

orchestrate these steps. n8n's visual interface and extensive integrations
could simplify the creation and management of this video generation
pipeline.

7. Automated Upload (Future): Explore APIs for YouTube/Instagram to

automate the video upload and scheduling process.
This video pipeline would represent a powerful marketing and user
engagement arm for the AutoStocks service.

 Scalability and Performance:

o For a larger user base, investigate more scalable infrastructure (e.g., Docker
containers managed by Kubernetes, using message queues like RabbitMQ or
Kafka for decoupling pipeline stages) and optimized database interactions.

o Consider paid API tiers for higher rate limits and more reliable data access.