# FinGuard AI — Technical Project Report

Document ID: MF-2026-07-TPR-01  
Status: structured engineering draft; results not yet publication-approved  
Institution: MindforgeAI · Chatake Innoworks Private Limited

## Executive summary

AI-driven financial risk detection, fraud prevention and intelligent compliance system. This report records the engineering problem, evidence, implementation decisions, verification work and limitations without converting a prototype into an unsupported production claim.

## 1. Problem definition

Primary engineering question: **How can suspicious activity be detected while keeping evidence legible to human reviewers?**

### Required completion evidence

- user and stakeholder definition;
- measurable functional and non-functional requirements;
- explicit scope and exclusions;
- responsible-use and safety boundary.

## 2. Domain research and requirements

Insert reviewed domain sources, competing methods, user workflow, constraints and acceptance criteria. Every source must be cited and retained in the project research register.

## 3. Dataset, preprocessing and features

Record dataset origin, licence, schema, data dictionary, missing-value policy, exploratory analysis, leakage controls, preprocessing pipeline, feature rationale and train/validation/test split. If no dataset is used, document the equivalent sensor, rule, simulation or document corpus.

## 4. System and model architecture

Add a traceable architecture diagram covering inputs, storage, processing, model or rule layer, API, interface, monitoring and human decision points. Record environment versions and reproducible run commands.

Observed technology surface: Python, HTML, CSS, JavaScript, Mobile workspace.

## 5. Implementation and verification

Verified at 17 August 2026: React lint and production build passed; the frontend is connected for local review at port 5175.

Known limitation: Backend, Flutter, model and graph components remain unverified.

Next gate: Establish the canonical source tree and reproduce backend, mobile and model workflows.

Do not add accuracy, latency, scale, safety or deployment claims until the corresponding test artifact is linked in the evidence matrix.

## 6. Deployment and operations

Reserve evidence for environment configuration, secrets handling, infrastructure, health checks, logs, monitoring, rollback, privacy, accessibility and operating cost. A proposed Android application must remain a proposal until a reproducible build exists.

## 7. Results and discussion

Pending reproducible experiment outputs. Required table: metric, baseline, experiment configuration, result, uncertainty, artifact path and reviewer.

## 8. Limitations and future work

Current limitation: Backend, Flutter, model and graph components remain unverified.

Capstone continuation remains open after repository reconciliation, reproducibility review and programme approval.

## 9. Conclusion

Complete only after the evidence matrix supports the project objective.

## References and appendices

Use a consistent citation style. Append dataset cards, model cards, API specification, test report, screenshots, diagram sources and change log.