CrossCheck

CrossCheck extracts claims from suspicious messages and verifies them against authoritative evidence to expose impersonation—even when scammers reuse real companies and registrations.

Comment

Inspiration

Modern impersonation scams are difficult to detect because they are often built from real facts.

A scammer can reuse a real company, a genuine registration number, legitimate branding, and public company information — then substitute a fake website, phone number, email address, or relationship.

That creates a dangerous failure mode for traditional scam detection: a message can contain many individually true facts while the identity assembled from them is false.

We wanted to move beyond asking:

“Does this message look suspicious?”

and instead ask:

“What is this person claiming, and does independent evidence support those claims?”

That became CrossCheck.

What it does

CrossCheck is an evidence-backed impersonation investigation system.

A user submits a suspicious communication. CrossCheck then:

  1. uses AI to extract atomic factual claims and preserve the exact supporting quote,
  2. routes each claim to an appropriate verification mechanism,
  3. checks authoritative or public evidence,
  4. correlates the findings,
  5. returns explicit evidence states instead of a vague scam probability.

CrossCheck uses four evidence states:

  • VERIFIED_BY_AUTHORITATIVE_SOURCE
  • CONTRADICTED_BY_AUTHORITATIVE_SOURCE
  • CONSISTENT_BUT_NOT_IDENTITY_PROVING
  • NO_AUTHORITATIVE_DATA

The core design principle is:

AI decides what needs investigation. Evidence decides what is true.

The language model never directly assigns a claim as verified or contradicted.

Flagship investigation

Our final demo investigates IPO Horizon, which claimed to represent Horizon Financial Planning Limited.

The result is intentionally interesting because some of the scammer's facts are genuine.

CrossCheck verifies that:

  • Horizon Financial Planning Limited is a real active UK company using Companies House.
  • FCA Firm Reference Number 307222 is genuine.

But it also finds that:

  • the FCA identifies IPO Horizon as a clone firm,
  • the genuine authorised firm has no connection with it,
  • the supplied website/contact information conflicts with the regulator's records.

The final investigation produces:

4 claims investigated · 2 verified · 2 contradicted · 0 unresolved

This demonstrates our central insight:

Real facts can still form a fake identity.

How we built it

CrossCheck separates language understanding from truth determination.

The AI layer uses the OpenAI Responses API to understand unstructured suspicious communications, extract grounded claims, preserve source quotes, and propose verification routes.

The deterministic verification layer is written in Python and checks those claims using evidence sources such as:

  • Financial Conduct Authority records and clone-firm warnings
  • Companies House legal-entity records
  • RDAP domain provenance
  • receiver-reported email authentication evidence
  • explicitly encoded official policy/process evidence

Evidence is normalized into structured objects with provenance, source information, findings, and limitations. The correlation layer then determines where individually plausible facts conflict.

The frontend is built with React, TypeScript, and Vite. The interface is designed as an evidence workbench rather than a traditional AI chatbot: users can inspect the claim, source, finding, provenance, and evidence boundary behind each conclusion.

Why it is not just an LLM wrapper

A common approach would be:

message → LLM → scam probability

CrossCheck instead uses:

message → grounded claims → verification routes → authoritative evidence → deterministic evidence states

The model cannot simply decide that a claim is true.

This separation also reduces prompt-injection risk. A suspicious message can contain instructions telling the AI to mark it as legitimate, but those instructions cannot create authoritative evidence or directly change the deterministic evidence state.

Challenges we faced

Our first flagship scenario was a fake NVIDIA recruiter investigation.

The pipeline technically worked, but the evidence did not.

Public information could establish some company and domain facts, but it could not reliably prove the identity of the human sender. Too many important claims remained unresolved.

Instead of making the result look stronger than the evidence supported, we rejected that scenario.

That forced us to rethink the project around a stricter question:

What can we actually verify independently?

Research into regulated clone-firm fraud gave us a much stronger case. The FCA warning for IPO Horizon allowed us to show a real company, a real regulatory number, and a false claimed relationship in the same investigation.

We also had to solve several implementation challenges:

  • keeping claim extraction stable across live model runs,
  • preventing the LLM from assigning truth states,
  • binding both clone and genuine-firm identities to the same authoritative warning,
  • preventing missing evidence from becoming an automatic fraud conclusion,
  • preserving evidence provenance,
  • and making arbitrary manually pasted input work instead of only a prepared demo fixture.

What we learned

The biggest lesson was that fraud detection and verification are not the same problem.

AI is very useful for understanding unstructured communication, but model confidence is not a strong truth layer.

Authoritative evidence is stronger.

We also learned that “unknown” is an important result. If CrossCheck cannot independently establish a claim, it should say so rather than manufacture certainty.

Finally, sophisticated impersonation does not require every fact to be fake. It can be created by taking several true facts and connecting them with one false relationship.

Validation

We tested CrossCheck beyond the prepared demo.

The current project passes:

90 Python tests
13 frontend tests
lint
production build

We also ran the full live flagship pipeline five consecutive times.

Every run completed successfully with:

4 claims · 2 verified · 2 contradicted · 0 unresolved

Observed end-to-end latency across those runs was approximately 5.3 to 10.1 seconds.

The result counts are generated by the backend; they are not hard-coded.

A separate claim-extraction benchmark produced:

12/12 successful responses
15/15 expected critical claims recalled
0 unsupported hallucinated claims
100% schema-valid output
0 invalid verification routes

These are prototype validation measurements, not claims of production-level accuracy.

Safety boundaries

CrossCheck deliberately avoids claiming more than its evidence establishes.

A real company does not prove the sender works there.

A genuine regulatory number does not authenticate the person using it.

A registered domain does not prove human identity.

Valid SPF, DKIM, or DMARC does not automatically prove that a sender is trustworthy.

And missing public evidence does not automatically mean fraud.

When strong evidence is unavailable, CrossCheck keeps the claim unresolved.

Unknown is a valid result.

What's next

We would like to expand CrossCheck with additional regulatory jurisdictions and authoritative evidence adapters, independent DNS/DKIM cryptographic verification, multi-channel correlation across email/SMS/calls/websites, and browser or email integrations.

The long-term goal is to provide an evidence layer before someone sends money, credentials, or sensitive information.

Built for ForgeHacks Online 2026 — Cybersecurity Track.

CrossCheck turns scam detection into evidence-backed investigation.

AI decides what needs investigation. Evidence decides what is true.

Built With

Share this project:

Updates

Submission history