CaseProof

• 

  Golden-hour priority, supported findings and unresolved payments help the analyst choose a justified next action.

• 

  Follow bank-reported transfers and inspect observation limits. A traced balance is not a confirmed hold or recovery.

• 

  Compare extracted details with their cited original evidence before using them in the investigation.

• 

  Customers select disputed payments, describe the incident and attach supported evidence through a guided report.

• 

  Inspect the approved handoff: payment inventory, reviewer rationale and money trace preserved as delivered.

• 

  An independent reviewer checks readiness and approves the exact case version with a written reason.

Inspiration

When someone reports a payment scam, the analyst’s first challenge is deciding what the evidence actually supports. A receipt, a frightened customer’s explanation and bank transactions may tell different parts of the story. Another debit might be unrelated. Meanwhile, money may already have moved onward. We built CaseProof around one question: What should the analyst do next - and can they justify that action?

What it does

CaseProof turns a payment-scam report into a source-linked investigation brief and a separately reviewed handoff. The customer selects the disputed payment, explains what happened and uploads supporting evidence. The analyst receives an arrival alert, a bank-timed golden-hour priority signal and a recommended next action. From one workspace, the analyst can:

• Compare extracted details with the original evidence.
• Distinguish customer statements from bank-confirmed information.
• Follow observed transfers through an interactive Money Trail.
• Request information that could change the decision.
• Keep additional debits separate until the customer explicitly confirms them. A reviewer then authorises the current case version. CaseProof delivers the approved report to two synthetic receivers, records their acknowledgements and retains an owner and next action.

The output is a defensible investigation handoff - not simply an AI summary.

How we built it

The interface uses React and Vite, supported by a Python/FastAPI backend. The cloud deployment uses Cloud Run, Firestore, Cloud Storage, BigQuery, Cloud Tasks and Cloud Scheduler. Document AI reads uploaded evidence, while Gemini on Vertex AI supports structured extraction and investigation assistance. Financial totals, payment allocations, readiness and approval checks remain server-controlled. A human reviewer authorises delivery. The practice experience generates fictional banking records at runtime. Visitors can submit new complaints and upload supported evidence without creating an account; they are not restricted to replaying one completed case. The repository includes our scope, product requirements, technical specification, setup instructions and source provenance.

Challenges we ran into

The hardest work was preserving the meaning of information as it moved through the system. An extracted amount is not automatically verified by the bank. An additional debit is not automatically part of the complaint. A queued packet is not a delivered report. New evidence must not silently inherit an older approval. We also encountered real operational failures: provider outages, spending-cap enforcement, a stale provider-failure circuit and an unavailable deployment image. Resolving these reinforced the importance of explicit failure states, bounded retries, durable jobs and reproducible deployment.

Accomplishments that we're proud of

The local release passed 380 backend tests and 88 frontend tests. After cloud recovery, a fresh public complaint passed 51 browser checks, covering evidence processing, customer clarification, independent review, both delivery acknowledgements, the readable report and persisted follow-up. Thirty automated accessibility scans reported no violations in the tested states. These results establish a working prototype, not production banking certification or complete accessibility conformance.

What we learned

A polished interface needs equally clear decision boundaries. Our most useful improvements made the next action easier to understand: showing urgency prominently, organising source inspection, explaining role handoffs and separating delivery from resolution. We also learned to treat AI output as something an analyst must inspect, rather than something the interface should automatically present as established fact.

What's next for CaseProof

We want to evaluate CaseProof with practising fraud-response analysts and measure time to a supported first action, unnecessary clarification requests and reviewer rework. Bank integrations, production identity and operational validation are future work. The current prototype uses synthetic banking data and receivers; it does not freeze funds, issue refunds or guarantee recovery.

Built With

• bigquery
• cloud-run
• cloud-scheduler
• cloud-storage
• cloud-tasks
• docker
• document-ai
• duckdb
• fastapi
• firestore
• gemini
• github-actions
• google-cloud
• javascript
• nginx
• playwright
• pytest
• python
• react
• sqlite
• tesseract
• vertex-ai
• vite
• vitest