NOTE: Please check out our Vercel link below to see our demo (the QR code in the video isn't updated) - thank you!

Inspiration

Older adults are increasingly targeted by scams that exploit trust, fear, and urgency.

In 2025, Americans 60 and older filed 201,266 complaints with the FBI and reported $7.7 billion lost, 59% more than the year before. The average loss was $38,500. 12,444 of them lost more than $100,000.

This trend is everywhere: reported losses from older adults went from about $600 million in 2020 to over $3 billion in 2025. Reports of six-figure losses grew 496%, and those reports were 6% of cases but 70% of the money. Bank transfers carried more of the losses than any other payment method. Counting the people who never report, the FTC puts the real cost of fraud against older adults at somewhere between $13.3 billion and $119.5 billion for last year alone.

AARP estimates older Americans lose $28.3 billion a year to financial exploitation, and 72% of it, $20.3 billion, is taken by someone they know: family, friends, caregivers. 87.5% of those victims never report it. In a CFPB study of bank suspicious activity reports, older adults who knew the suspect lost an average of $50,200, about three times the $17,000 lost to strangers. And FinCEN’s review of 155,415 bank filings found that in elder theft cases, adult children were the most frequent perpetrators.

A lot of the scam projects we found, including several from hackathons this month, work the same way: an AI flags the payment and a family member approves it. We noticed that design hands the approve button to the people who take the most.

A caller pretending to be a grandchild in trouble or a bank employee can make a victim believe a transfer is necessary and legitimate. Once someone has been convinced, warnings and fraud education may not be enough. Handing over approvals for large purchases to authorized users is also not always the safest way forward, since they can be malicious actors.

Older adults are vulnerable from all sides, so they need to be protected from all sides too - without giving power over their finances exclusively to their children, and definitely not to an AI agent.

This led us to explore a different approach: what if financial protection did not end when the customer approved a payment?

So we built Second Key, a simulation built around Margaret, a fictional 72-year-old banking customer. Our goal is to test whether a scammer can manipulate the conversation; and whether the system can still prevent an unsafe transaction from being executed.

What it does

Second Key is an AI-powered scam-prevention simulation that tests social-engineering attacks against an older banking customer. Participants can interact with Margaret through text and voice, attempting attacks such as prompt injection, payment-recipient substitution, replaying an old approval, and exploiting conflicts of interest.

Our key differentiator is that we do not rely solely on the victim recognizing a scam or refusing to approve a payment. Even when a customer has been manipulated into approving a transaction, Second Key introduces an independent authorization layer that checks whether the payment can safely proceed.

A deterministic policy engine evaluates transactions separately from the conversational AI. Authorization is bound to the transaction details, so changing the recipient or amount after approval invalidates the original authorization. Replay protection and conflict-of-interest checks provide additional safeguards.

The live dashboard makes these decisions visible, showing which security rule was triggered, whether the payment was refused, and the sequence of events behind the outcome.

How we built it

We built the conversational experience using Claude to interpret interactions and identify signs of manipulation, and Cartesia for speech-to-text and voice generation.

SpacetimeDB maintains the shared room state, including players, turns, replies, and outcomes. Its subscriptions keep connected participants synchronized, while reducers provide controlled entry points for state changes.

The financial security layer is deliberately separated from the conversational model. Instead of allowing the AI's assessment to determine whether money can move, deterministic policy checks independently evaluate authorization, transaction integrity, approval reuse, and conflicts of interest.

We integrated Capital One's Nessie sandbox to test banking interactions without moving real customer funds. We also built a live dashboard that exposes the conversation, security decisions, and transaction outcomes, making it possible to inspect not just what the AI said, but what the system actually allowed.

Challenges we ran into

Our biggest challenge was designing a realistic scam simulation without making financial security dependent on the AI behaving correctly. A model can be persuaded to overlook suspicious context, and a victim can genuinely believe a scammer. Neither should automatically mean that a payment is safe to execute.

We also needed to account for attacks that happen after approval. A payment can initially appear legitimate, only for its recipient or amount to change before execution. We addressed this by binding authorization to transaction details and rejecting changes that invalidate the original approval.

Finally, we wanted security decisions to be explainable. Rather than displaying only a generic warning, the dashboard records the decision and the rule behind it, helping us understand how an attack unfolded and where a safeguard intervened.

Accomplishments that we're proud of

We're proud to have built an interactive environment where participants can red-team an AI-driven banking scenario and observe the security layer respond in real time.

Our tests cover multiple attack classes, including prompt injection, transaction modification after approval, replay attacks, and attempts at self-approval. In our payee-substitution test, changing the recipient after approval invalidates the transaction fingerprint and causes the payment to be refused.

Most importantly, Second Key demonstrates a different layer of protection: even when social engineering succeeds at convincing the customer, it does not automatically have to succeed at moving their money.

Rather than treating customer approval as the only meaningful checkpoint, our prototype demonstrates how an independent layer can validate a transaction before release.

What we learned

We learned that protecting older adults from scams requires more than detecting suspicious language or building a model that is harder to manipulate. Social engineering exploits human trust, and a person can willingly authorize a payment while acting on false information.

We also learned that conversational intelligence and financial authorization solve different problems. AI can help interpret an interaction, but critical financial decisions need explicit, independently enforced rules.

Finally, we learned the importance of transaction integrity and auditability. A system should be able to explain not just whether a payment was refused, but which condition caused the refusal and how the transaction changed.

What's next for Second Key

We want to expand our simulations to cover more real-world scams targeting older adults, including family impersonation, fake bank support, investment fraud, and multi-stage attacks that combine conversational pressure with transaction changes.

Our next step is to explore how this independent authorization layer could integrate with real banking payment workflows, including appropriate risk-based holds and additional verification before funds are released.

We also want to work with banks, researchers, and organizations focused on elder-fraud prevention to evaluate these safeguards against realistic attacks.

Our long-term vision is a financial system where older adults can benefit from digital banking and conversational AI without being left unprotected simply because a scammer convinced them to say yes.

Built With

  • ai-safety
  • capital-one-nessie
  • cartesia
  • claude
  • cybersecurity
  • deterministic
  • financial-technology
  • fraud-prevention
  • next.js
  • policy
  • react
  • real-time-applications
  • social-engineering
  • spacetimedb
  • typescript
  • voice-ai
Share this project:

Updates

Submission history