Inspiration
Most scam protection judges one message at a time, but real scams unfold across a whole conversation. A harmless-looking “reply NO if this wasn’t you” text can be the first step toward a SIM swap or number transfer, and by the time the damaging request shows up, the context is gone. We built Interlock for the T-Mobile Scam & Fraud Challenge around a simple question: what if protection followed the entire thread and stepped in right before irreversible loss, instead of just slapping a warning banner on a single text? We wanted something that helps people understand why a situation is risky and what to do next.
What it does
Interlock scores a conversation rather than a message, tracking a scam through six stages: contact, hook, isolation, escalation, extraction, and post-loss. It places a different safeguard at each stage, including reasoned warnings, campaign matching against previously reported patterns, and an OTP Guard for passcode requests made during a call. For sensitive account changes like a number transfer, it proposes a cooling-off hold that gives the customer a moment to verify independently without taking control away from them. If someone thinks they were targeted, it offers a straightforward recovery checklist. The detection engine runs locally in the browser, so message content stays on the device unless the user chooses to report a derived signature.
How we built it
Interlock is a web prototype deployed on Vercel, with a detection engine that runs entirely client-side. We modeled scams as a staged kill chain and built the scoring to accumulate evidence across a thread, so shifts in tactic like urgency, secrecy, and credential requests raise risk over time. Each stage maps to a specific safeguard, with the strongest one reserved for account actions a carrier uniquely controls. To test it, we wrote synthetic scam and legitimate conversations, held some out for evaluation, and added adversarial tests and decision receipts that show how each verdict was reached.
Challenges we ran into
The biggest challenge was having no access to real messages or carrier accounts, so everything had to be built and evaluated on fictional scenarios, and we had to be careful not to overclaim. We also had to avoid crying wolf, since an opening message can be completely legitimate and the system should say “nothing conclusive yet” until evidence builds. Balancing privacy with shared intelligence was tricky too, because campaign matching is more useful with shared signals, but we wanted message content to never leave the device. Finally, we wanted the evaluation to be honest, so we published our methodology and limitations instead of letting a confident-looking score imply certainty.
Accomplishments that we’re proud of
On our held-out synthetic set, Interlock warned on 95% of 40 scam threads with zero false alarms across 50 legitimate conversations. In scripted scenarios, warnings arrived a median of 60 seconds before the final action, which is the window that actually matters. We’re also proud that we published our evidence, adversarial tests, and limitations right alongside the demo so the work can be questioned. These numbers come from an authored synthetic set, not real-world performance, and we say so clearly.
What we learned
We learned that scams are sequences, not single events, and that conversation context is the strongest signal for catching them. Timing matters as much as detection, because a warning that arrives after the passcode is read out is worthless. We also learned that protection works better when it explains itself and leaves the final decision with the person instead of taking control away. Being upfront about what a prototype can’t claim turned out to build more trust than a polished accuracy number would have. What’s next for Interlock
The next step is validating Interlock against real, privacy-preserving data through a carrier partnership, since our current results are synthetic only. We’d also like to connect the cooling-off hold to real account-change flows so it becomes an actual carrier control rather than a simulation. On the privacy side, we want a formal review of what the similarity signatures reveal and strengthen the reporting model. Beyond that, we plan to expand coverage to more scam types and languages, keep red-teaming against adaptive attackers, and turn the recovery checklist into guided, one-tap steps.
