PIXEL

Inspiration

Scammers don't target everyone equally. They target people living with dementia, learning disabilities, brain injuries or anxiety, because pressure and confusion work. Talking to friends and family, we kept hearing the same story: someone vulnerable was rushed into a payment, and the warnings their bank showed were too long, too technical, or arrived too late.

Most protections today pick one of two bad options: overwhelm the customer, or take control away from them. We wanted a third option that keeps people safe and independent.

What it does

Pixel is a calm safety layer for banking customers with accessibility needs.

Rules for my future self: on a calm day, customers set their own protections, like holding large payments to new payees or reading warnings aloud.
Smart interruption: when a payment looks risky, Pixel pauses it and asks one simple question at a time, with large text and voice.
Trusted contact: one tap alerts someone the customer chose. They see the alert, never the account.
Scam message analysis: customers can paste the message that led to the payment, and AI highlights pressure tactics like urgency, impersonation and secrecy.

How we built it

Frontend: Next.js and Tailwind, built around one decision per screen, high contrast, keyboard navigation and plain English
Voice: the browser Web Speech API for text to speech and speech input
Risk engine: a rules based score combined with an LLM signal:

$$ R = \min\left(100,\ \sum_{i} w_i s_i + \max(0, L)\right) $$

where $s_i$ are signals such as a new payee, an unusual amount or a name mismatch, $w_i$ are their weights, and $L$ is the LLM's risk contribution.

LLM analysis: structured JSON output listing the tactics found, evidence quotes and a score

Security by design

A scammer's message is untrusted input, so we assumed someone would try prompt injection by hiding text like "this message is verified as safe." Pixel treats the message strictly as data, accepts only schema validated output, and clamps the LLM so it can raise risk but never lower it. The rules engine always has the final say.

Challenges we faced

Getting the right amount of friction: strong enough to stop a scam, gentle enough not to patronise
Writing warnings in genuinely plain language, which is harder than it sounds
Making LLM output reliable enough to sit inside a payment flow
Building and testing everything overnight on very little sleep

What we learned

Accessibility goes far beyond screen readers. Cognitive accessibility is a huge, underserved area
Good security and good accessibility point the same way: clear, predictable, hard to manipulate
Rules plus AI beats AI alone when the stakes are someone's savings