Inspiration
Financial fraud rarely looks like fraud at first glance.
It looks like an ordinary invoice, a legitimate supplier, a routine payment, or a perfectly reasonable entry buried among thousands of transactions. The real problem is not simply finding unusual numbers; it is reconstructing the scheme behind them without falsely accusing legitimate businesses.
Cases such as the Satyam scandal showed us how fraudulent invoices and manipulated accounting records can survive traditional auditing processes for years. In Mexico, the problem is especially relevant: fake suppliers, shell companies, fabricated invoices, simulated transactions, tax evasion, and money laundering can all hide inside otherwise normal company books.
At the same time, simply throwing every transaction into a large language model is not a realistic solution. It is expensive, difficult to scale, and can introduce uncertainty into a domain where conclusions need to be explainable and verifiable.
That led us to a different question:
What if AI did not have to investigate everything?
Instead of asking an expensive model to blindly search through an entire company's financial history, we could first use deterministic, inexpensive checks to identify transactions and relationships that actually deserve investigation. AI could then spend its reasoning power where it matters most.
That idea became redflags.
Our goal is to build a financial investigation platform that helps auditors and investigators classify suspicious activity, determine its possible root cause, and trace the evidence behind that conclusion across historical financial records.
What it does
redflags turns company books into investigations.
Investigators can upload multiple financial books and datasets into the platform. Once enough information is available to begin an investigation, redflags automatically processes the records and searches for suspicious activity.
Instead of immediately sending every transaction to an LLM, redflags uses a layered investigation pipeline.
The first layer performs fast, deterministic checks over the financial records. These checks act as an inexpensive filter for suspicious behavior and help identify transactions, suppliers, invoices, and relationships that warrant deeper analysis.
This dramatically reduces the search space.
Only the relevant evidence is escalated to the heavier AI investigation layer, where agentic LLMs can reason across records, compare information, investigate relationships between companies, and help determine why something was flagged.
This allows redflags to investigate patterns such as:
- suspicious or potentially fake invoices,
- unusual supplier relationships,
- transactions involving possible shell companies,
- fabricated or inconsistent sales,
- suspicious money movement,
- potential tax-evasion patterns,
- and other deceptive financial activity.
Most importantly, redflags is designed around evidence rather than accusations.
The objective is not to have an AI produce a mysterious "fraud / not fraud" prediction. Investigators need to understand what triggered an alert, which records support it, how those records are connected, and why the system believes the case deserves further investigation.
The result is a workflow where inexpensive deterministic computation handles the enormous volume of normal financial activity while more powerful models concentrate on the small subset of records where deeper reasoning can actually provide value.
How we built it
We designed redflags as a hybrid system rather than a single AI model.
The first challenge was deciding how financial transactions should be classified. A traditional neural-network approach initially seemed attractive, but it quickly exposed a fundamental problem: supervised models require labeled examples of fraud, while unsupervised models can discover statistical clusters without necessarily producing categories that have meaningful investigative value.
Instead, we developed a deterministic screening layer based on simple conditions and financial red flags.
These "dumb checks" are intentionally inexpensive and understandable. Their purpose is not to independently declare that fraud occurred. They identify anomalies and narrow thousands of records into a much smaller collection of evidence worth investigating.
That evidence can then be passed into the heavyweight reasoning stack.
The AI investigation layer is designed to reason across the flagged records and supporting company information, connecting evidence that would be difficult to understand by examining transactions independently.
On top of the investigation pipeline, we built a web application that lets users upload company books and follow an investigation from ingestion to analysis. The frontend communicates with our backend to process the uploaded financial data, determine when enough evidence exists to begin an investigation, run the initial classification pipeline, and surface the resulting findings.
We also structured development around a GitHub Issue-driven workflow. Issues gave both human developers and coding agents clearly scoped problems to solve, while strict unit tests and CI/CD checks helped prevent independently developed components from breaking the larger investigation pipeline.
This became particularly important because we used AI agents extensively during development. Rather than treating agents as autonomous replacements for the team, we treated ourselves as supervisors: defining problems, establishing constraints, reviewing implementations, and using automated testing as the shared contract between human-written and agent-written components.
Challenges we ran into
One of our biggest challenges was false positives.
In financial investigations, incorrectly flagging a legitimate supplier is not a harmless classification error. A false accusation can damage a business relationship, cost a supplier a customer, or send investigators in completely the wrong direction.
That forced us to think differently about what our system should output.
Instead of optimizing only for classification, we focused on building a path from every suspicious result back to the evidence and deterministic signals that caused it to be investigated.
Another major challenge was deciding where AI actually belongs in the pipeline.
Sending entire financial books directly into an LLM would have been simple, but it would also have been expensive, inefficient, difficult to scale, and harder to verify. Finding the boundary between deterministic analysis and probabilistic reasoning became one of the central architectural decisions behind redflags.
We also faced infrastructure constraints.
Financial records are highly sensitive, so we explored running the heavyweight AI investigation locally rather than transmitting company books to external infrastructure. We initially envisioned a compute cluster capable of serving as the investigation engine. Cloud inference would have been easier and potentially faster, but it introduced a tradeoff around privacy and control of client data.
Finally, our team had to coordinate human development with agentic development. Giving several agents broad access to a rapidly changing codebase can create conflicts very quickly. Moving toward small GitHub Issues, strict interfaces, tests, and CI/CD gave us a way to parallelize development while maintaining a coherent product.
Chain-of-Thought ;)
<think agent=”Filip”>
The task given does not allow us false positives. We need to be confident in our decisions and have a highly verifiable path up to our conclusions. For the application development itself we need a system that’s scalable to let our whole team collaborate, both with each other and together with agentic agents. For us that turned out to be a Github Issue driven workflow, along with strict unit tests our CI/CD pipeline turned out to be incredibly effective.
</think>
<think agent=”Sondre”>
Stories like the Satyam scandal in 2009 where audits from a reputable firm never found fraudulent invoices worth a billion dollars made me want to learn more about financial auditing, and invoice fraud specifically. We made an overall plan for how we wanted our agent to solve the auditing problem, then let AI agents do most of the heavy lifting writing the code while we worked as supervisors, defining the problems and directing the solutions. We ran into disagreements in the group about our vision for the product, and into the problem of running the model locally with no connection. Originally we wanted a compute cluster to act as the AI agent; at the same time we considered settling for a faster cloud server, which would have meant weaker security and less privacy for the client's files.
</think>
<think agent=”Pedro”>
The task provided by the organizers states that the it should approached like an investigatio
</think>
<think agent=”Ulises”>
The user is asking for a tool to inexpensively but deterministically classify and determine the reason for the label when it comes to suspicious activity in company books. I can use a Convolutional Neural Network to classify and then feed to an LLM to analyze the reason for the classification. However, this is ineffective because unsupervised Neural Networks would just group everything into a big set without meaningful data for the LLM to analyze and a supervised Network would require labels, which we don’t have. It would be best to use “dumb checks” and then pass the books through agentic LLMs which can dig into other company’s books and further investigate. This sounds good. I should implement this into a web application for an easy to develop and easy to use interface.
</think>
Accomplishments that we're proud of
We are especially proud that redflags became more than a fraud-classification demo.
We built the project around the idea that financial AI should be investigative, explainable, and selective.
Rather than hiding everything behind one model prediction, our architecture separates inexpensive anomaly detection from expensive reasoning. This gives us a system that can potentially scale to much larger financial datasets without requiring an LLM to examine every transaction.
We are also proud of the investigation workflow itself. A user can move from uploading raw company books to seeing suspicious activity classified and escalated for deeper analysis within the same product.
Another accomplishment was successfully integrating agentic software development into our own engineering workflow. GitHub Issues, automated testing, and CI/CD allowed humans and agents to work simultaneously without abandoning engineering discipline.
Perhaps most importantly, we moved away from the tempting idea of building a black-box "fraud detector."
redflags does not try to replace the investigator. It tries to give the investigator a dramatically better starting point.
What we learned
The biggest lesson was that not every AI problem needs more AI.
Some of the most valuable parts of redflags are deliberately simple.
A deterministic rule that costs almost nothing to execute can eliminate thousands of irrelevant records before an expensive model ever becomes involved. The combination of simple computation and sophisticated reasoning can be much more useful than applying sophisticated reasoning indiscriminately.
We also learned that explainability becomes part of the product when AI operates in a high-stakes domain.
A suspicious score alone is not enough. Investigators need the underlying transactions, relationships, anomalies, and reasoning that produced it.
Another important lesson came from working with coding agents. Agents are extremely effective at implementation when the problem is clearly defined, but architecture, constraints, verification, and product direction still require deliberate supervision. Our development process became significantly more effective once we treated issues and tests as contracts between developers and agents.
Finally, we learned how important privacy is for financial AI. The question is not only whether a model can analyze a company's books, but also where those books go while it does so.
That consideration shaped our exploration of local inference and dedicated compute infrastructure.
What's next for redflags
Our next step is to turn redflags from a hackathon investigation prototype into a broader financial-forensics platform.
We want to expand the deterministic detection engine with additional accounting and fraud heuristics while keeping every trigger understandable and auditable.
We also want the investigation agents to move beyond analyzing isolated suspicious transactions. Future versions could construct relationships between suppliers, companies, invoices, accounts, and transactions, allowing investigators to explore an entire suspicious network rather than individual alerts.
A major direction for us is deeper evidence collection. When redflags discovers something suspicious, the system should be capable of gathering supporting context, comparing records across books, testing alternative explanations, and presenting investigators with an evidence-backed case rather than a single classification.
We also want to continue exploring private inference infrastructure so organizations can investigate sensitive financial information without unnecessarily exposing their books to external services.
Ultimately, we envision redflags as an AI-assisted financial investigation workspace:
deterministic where certainty matters, agentic where reasoning matters, and human-controlled where judgment matters.
The goal is not to have AI accuse companies of fraud.
The goal is to help investigators find the red flags worth investigating — and give them the evidence to understand why.
Log in or sign up for Devpost to join the conversation.