Second Look 3

A second look before sending money you can't get back.

Comment

Inspiration

The scams that hurt credit union members most don't look like fraud on paper. The member sends the money themselves, so the payment is authorized and the usual tools let it through. Sound's challenge asked how to protect members in that moment without making normal life harder. We wanted a second look before the money leaves, not just a score.

What it does

Second Look is protection members switch on inside the Sound app: one toggle, no new app. Most of the time it stays quiet. When a payment matches a known scam pattern, it adds a checkpoint that fits the payment type: wires, ACH and external transfers can be paused for up to 4 hours, P2P gets a check before the member hits send, and large cash withdrawals get a conversation in the branch. Every flag shows its evidence, such as "first wire in 2,411 days, new recipient, 4.77× your usual."

While a payment is paused, a Sound employee gets the case with that evidence and a short call guide with scam-specific questions. The member can tap "Talk it through," a calm chat that explains why the payment was flagged, says what it can't know, and suggests independent checks like calling a number they already had. They can also open "Something feels off?" before any money moves, ask for a person at Sound, or start recovery if money already went out. The member always decides: "It's me, send it now" is one tap away. Sound stops a payment outright only after a takeover is confirmed.

How we built it

Node and TypeScript with Hono, a SQLite database, and plain HTML/JS screens: a member app styled like Sound's and an employee console. A replay engine plays each member's timeline from Sound's synthetic events. A payment state machine enforces only the powers Sound already has: holds cap at 4 hours, P2P is never held, and a stop is allowed only after a takeover is confirmed.

Detection is four plain rules over the kit's fields, not AI, so employees and regulators can see exactly why something fired:

  • R1 family emergency: a first wire in over a year, to a new recipient, at 3× or more the usual amount.
  • R2 account takeover: a password or profile change, then a new recipient, then a payment within 7 days.
  • R3 escalating pattern: growing P2P payments to one new recipient, then a first-ever wire.
  • R4 branch cash: a large cash withdrawal soon after asking about limits.

Alerts follow three tiers: quiet inbox items by default, a banner next to the thing it concerns, and a phone interruption only when money is about to move.

AI does one job: the member chat, powered by Claude. It gets the case evidence, the payment details and the conversation. It can't move money, send messages, click links or call anyone, and it never says "definitely a scam" or "definitely safe." If the AI is unavailable, the chat falls back to labeled scripted replies.

Challenges we ran into

  • Legitimate payments. M1057's $51,586.52 home closing wire triggers the same rule as Linda's scam wire. We kept that false positive in on purpose: the answer is a respectful release in minutes, not a looser rule.
  • Restraint. M1037's payment doesn't trigger anything, and we didn't force it to. Not every new recipient deserves an interruption.
  • Honest misses. M1102 wired $5,000 to a fake "federal agent," and no rule catches it. We show it in the demo instead of tuning rules to the answer key.
  • Privacy. Detection uses only payment data Sound already has. We never read texts, calls or email. In the demo, chat is kept only for the session. In our proposal, the employee sees the case evidence, and the member chooses whether to share the chat.
  • Scope. We changed direction a few times and landed on a toggle inside Sound's app instead of a separate app members would have to find.

Accomplishments that we're proud of

  • On the synthetic data, the four rules fire on most of the scam journeys and on 8 of the 20 legitimate look-alikes, and each look-alike gets a fast, respectful release path. We used the answer key only to check our rules, never as an input, and a test fails if the app ever reads it. These are test results on synthetic data, not fraud performance.
  • Every pause, release and stop goes through a tested payment state machine. A hold really blocks the demo payment until a person or the member acts.
  • The whole demo runs on its own, with no outside services required. Even the chat has a fallback.
  • Every flag explains itself in plain words, to both the member and the employee.

What we learned

Rules decide when to step in, and conversation helps the member think. Showing a false positive and a missed scam openly built more trust than hiding them. The data is synthetic, so we don't claim real fraud performance.

What's next for Second Look

A 90-day pilot using the kit's metrics, with baseline and target assumptions stated up front. Then a 1 to 5 alert sensitivity setting, a plain-language case summary for employees, and the same help in calls, iMessage and Android texts, which needs OS or carrier support and member consent.

Built With

Share this project:

Updates