Report
Review
Main

Inspiration

We wanted to build more than a chatbot on top of expense data. Finance review is usually scattered across CSV exports, policy PDFs, manager approvals, fraud checks, and manual reporting, which makes the workflow slow and error-prone. PolyPilot was inspired by the idea of a single intelligent finance operations agent that could understand transaction data, enforce policy, surface risk, and help reviewers make faster, more grounded decisions. We were especially interested in exploring how deterministic systems, machine learning, and LLMs could work together in a trustworthy way instead of competing with one another.

What it does

PolyPilot is an all-in-one AI finance operations copilot for expense intelligence. It ingests raw corporate card transaction exports and transforms them into a structured review workflow. Users can upload transaction data, explore spend through natural-language questions, run policy compliance checks, detect suspicious or anomalous activity, review approval recommendations, and generate expense reports.

The system is designed around a realistic finance review flow. It preserves raw imported data, normalizes transactions, assigns synthetic organizational context such as employees and departments, and then layers policy, risk, approval, and reporting workflows on top. It also includes a cross-app assistant that can answer questions using grounded application context instead of generic responses.

How we built it

We built PolyPilot with a React + TypeScript frontend, a FastAPI backend for authoritative business logic, and Supabase as the database and storage layer. The frontend handles the user workflows and visualization experience, while the backend owns deterministic policy enforcement, risk scoring, approvals, reports, and AI orchestration.

Our data layer is centered around a structured finance schema in Supabase, including tables for raw transactions, normalized transactions, departments, employees, receipts, preapprovals, policy rules, policy checks, violations, risk scores, approval requests, expense reports, audit logs, chat sessions, and policy retrieval chunks. This gave us an end-to-end pipeline instead of a one-off demo.

For the data itself, we worked from a real transaction-style dataset. Because the source data did not include business context like employee, department, budget, receipts, or approvals, we built a deterministic synthetic business layer to make the downstream workflows possible and stable across re-imports.

For compliance, we implemented a deterministic policy engine that scans transactions against structured rules and records policy checks, missing context, and violations. To make the system adaptable, we also built policy extraction workflows that can turn policy text into structured draft rules instead of relying only on hardcoded logic.

For risk detection, we combined explainable rule-based signals with an unsupervised machine learning layer. In addition to deterministic checks such as duplicates, split transactions, weak categorization, FX inconsistencies, and posting lag anomalies, we used an Isolation Forest model to surface unusually suspicious debit transactions in unlabeled data. The model uses features such as amount behavior, merchant rarity, employee-level deviations, category-level deviations, proximity to approval thresholds, round-number behavior, and transaction timing. Instead of returning a black-box score, the system also exposes the top drivers behind each anomaly flag.

For AI orchestration, we used LLM-powered reasoning for query planning, conversational answers, reviewer briefs, approval recommendations, report narratives, and structured policy extraction. We also integrated retrieval-augmented generation (RAG) so policy explanations are grounded in policy documents stored as embedded chunks in pgvector rather than hallucinated from memory.

Challenges we ran into

One of the biggest challenges was turning raw transaction exports into something operationally meaningful. The original data had transaction-level fields, but not the richer business context required for policy review, approvals, and reporting. We had to design a stable synthetic organizational layer that felt realistic without pretending it came from the source data.

Another major challenge was anomaly detection on largely unlabeled financial data. Fraud and risky behavior are not always explicitly labeled, so we could not rely on standard supervised training. We had to think carefully about what kinds of patterns matter in expense data, engineer features that capture those behaviors, and combine unsupervised ML with deterministic review signals to keep the results useful and explainable.

RAG integration was also harder than it first appeared. It was not enough to simply embed policy text; we had to ensure the retrieved clauses actually supported explanations without interfering with deterministic enforcement. We wanted the model to explain policy, not invent it.

Building a truly cross-application assistant was another challenge. We were not aiming for a single chat box with generic answers; we wanted an agent that could understand the current page, the current workflow, and the system's actual data boundaries. That meant designing tool flows, grounding rules, response guards, and stateful context rather than relying on prompting alone.

We also spent a lot of time on policy flexibility. Hardcoding a single expense policy is easy for a demo, but allowing arbitrary policy text to be transformed into structured draft rules, while still preserving trust and human review, was a much harder systems problem.

Other challenges included balancing deterministic logic with AI flexibility, preventing hallucinated financial conclusions, making risk results interpretable, and keeping the full stack coherent across React, FastAPI, Supabase, rule engines, ML scoring, and conversational workflows.

Accomplishments that we're proud of

We are proud that PolyPilot feels like a real finance operations product rather than a narrow AI demo. We built an end-to-end workflow that starts with imported transaction data and extends all the way through compliance review, anomaly detection, approvals, and report generation.

We are especially proud of the hybrid intelligence design. Instead of letting AI make unchecked decisions, we combined deterministic policy logic, explainable risk signals, unsupervised anomaly detection with Isolation Forest, and grounded LLM outputs. That architecture gave us a system that is both intelligent and more trustworthy.

We are also proud of the database and workflow depth behind the product. The schema supports auditability, reproducibility, structured risk scoring, policy retrieval, report generation, and conversational context, which made the project much more robust than a superficial prototype.

What we learned

We learned that in finance workflows, trust matters as much as intelligence. Deterministic systems, audit trails, and explainability are not optional add-ons; they are the foundation that makes AI useful.

We also learned that unlabeled anomaly detection is as much a feature-engineering problem as a modeling problem. Isolation Forest became significantly more valuable once we paired it with domain-specific signals and surfaced interpretable reasons for its decisions.

Another big lesson was that RAG is only effective when retrieval boundaries are clear. Policy retrieval worked best when used for grounded explanation and support, not as a substitute for enforcement logic.

Finally, we learned that building a strong all-in-one agent is really a systems design challenge. Good prompts help, but what matters more is structured data, tool boundaries, application context, and careful orchestration across the stack.

What's next for Brim Challenge

Next, we want to make PolyPilot even more adaptive and production-like. That includes supporting real policy uploads with stronger automatic rule extraction, improving anomaly detection with reviewer feedback loops, and expanding the assistant into a more proactive finance workflow agent.

We also want to add richer document intelligence such as receipt ingestion and OCR, broaden the approval and reporting workflows, and deepen integrations with real accounting or expense platforms. On the ML side, we would like to move beyond unsupervised anomaly surfacing toward feedback-informed models that learn from reviewer decisions over time.

Most importantly, we want to keep pushing toward a finance copilot that is not just conversational, but operational: grounded in data, explainable in its reasoning, and genuinely useful in day-to-day review workflows.