AuditCore

Audicore full flow

Inspiration

[Tell us what motivated you: did you see a real case of fake-invoice fraud (EFOS)? Are you interested in fighting corporate fraud in Mexico? Was it the specific HackMTY challenge?] Corporate fraud in Mexico moves enormous amounts of money through shell companies (EFOS) and simulated invoicing schemes — and the tools to detect it are often opaque: "the AI says it's fraud" isn't proof that can hold up an accusation. We wanted to build a system that investigates the way a forensic auditor would: with citable, traceable, reproducible evidence.

What it does

AudiCore takes a company's 8 accounting CSV files and delivers a readable case file: which vendors or employees are involved in fraud, with what evidence, how much money, and why the leads that were not accused got dismissed.

How we built it

SQL rules engine on DuckDB: each rule is a pure function that runs a read-only query and returns signals (clues tied to an exact row), grouped into 5 fraud types (phantom vendor, kickback, round-tripping, threshold splitting, and revenue inflation).
A deterministic assembler that groups signals by scheme (union-find), decides whether there's enough evidence (≥2 independent evidence families, ≥3 citable records, an amount that reconciles), and if not, closes the lead with the exact reason.
Zero LLM in detection: the whole findings pipeline is SQL rules and fixed thresholds — same CSV + same seed always produces the same result, which is essential for a judge or auditor to reproduce the case.
Layered validation: every finding self-verifies (exhibits exist, amounts reconcile, narrative stays within the word limit) and then passes through an official validator before publishing.
[Add your real stack here: backend language, API framework, frontend if any, how you generate the HTML case file, etc.]

What we learned

That "prove before accusing" is harder than detecting: designing the materiality conditions to avoid accusing an honest vendor (a decoy) took more iteration than the detection rules themselves.
[Add concrete technical learnings: DuckDB vs. PostgreSQL, designing a deterministic engine, balancing recall vs. false accusations, etc.]

Challenges we ran into

Balancing recall (finding real fraud) against the false-accusation rate (not accusing an honest decoy) — both errors are weighted equally in scoring.
[Add team/time challenges: data limitations, hackathon time constraints, team coordination, debugging complex SQL rules, etc.]