Inspiration
A person can authorize a payment without realizing they are being scammed. They may believe they are protecting their savings, helping a family member, or paying a legitimate fee.
We wanted to create an opportunity to recognize that manipulation before the money moves. At the same time, showing the same warning for every transfer can frustrate members and make alerts easier to ignore.
That inspired AMY — Adaptive Money Yield Tool, a proposed safety feature inside Sound Credit Union’s banking app. Like a yield sign, AMY helps members slow down and check when the situation calls for it, while allowing ordinary payments to move forward.
What it does
AMY combines recipient risk, transaction risk, and the member’s answers to determine the appropriate level of verification.
First, it checks the actual destination account against a verified whitelist of official recipients, such as government agencies and utility providers. Ordinary payments to verified accounts can follow the normal confirmation flow.
For other payments, AMY evaluates available signals, such as a new recipient, an unusual amount, transfer frequency, and recent account changes. An unfamiliar account is treated as unverified—not automatically fraudulent.
When more context is needed, AMY asks targeted questions. Each answer updates the assessment and determines what happens next:
- Low risk: Finish sooner with fewer questions.
- Medium risk: Ask more detailed, relevant follow-up questions.
- High risk: Move directly to an appropriate intervention.
For example, a member paying rent might be asked how they verified the recipient’s account details. A member moving money to protect their account might be asked whether someone instructed them to transfer funds to a “safe account.”
The outcome can be normal payment confirmation, a specific warning with a verification suggestion, or a recommendation to pause and seek bank assistance. Members can also clarify their answers or request review.
How we built it
We structured AMY around a pre-transfer decision flow with four components:
- Recipient assessment: Exact account matching against a synthetic verified-recipient whitelist, with additional recipient risk indicators only where data is available.
- Transaction assessment: Evaluation of available payment and account-history signals.
- Adaptive questioning: A feedback loop that selects a relevant question, evaluates the answer, and adjusts the number and depth of follow-up questions.
- Intervention and review: Clear next steps for members and a proposed employee-review view containing the transaction, answers, and reasons for concern.
Our hackathon design uses synthetic or challenge-provided data. We do not assume access to private calls, messages, browsing history, or another bank’s internal account activity.
We designed the experience around both a potential scam and a legitimate transaction that initially looks unusual. This helped us consider how AMY should behave when its concerns are justified—and when they are not.
Challenges we faced
Balancing protection with friction
Asking more questions can uncover important context, but unnecessary questions can make banking frustrating. Our central challenge was deciding when another question adds value and when the system should stop.
Working with incomplete recipient information
A new recipient is not necessarily dangerous, and the absence of a fraud report does not establish safety. We had to distinguish verified information from uncertainty without presenting assumptions as facts.
Making warnings useful
A generic “Are you sure?” prompt provides little help to someone who trusts the person requesting money. We focused on questions and explanations tied to the member’s actual situation.
Preserving member autonomy
A legitimate member needs a clear way forward after being flagged. We included clarification and review paths, and distinguished a recommendation to pause from an enforced payment hold, which would depend on bank policy and supported capabilities.
What we learned
We learned that scam prevention requires understanding the context behind a payment, not just identifying an unusual transaction.
We also learned that the quality of a question matters as much as the number of questions. A well-chosen follow-up can reveal why someone is sending money and support a more appropriate response.
Finally, we learned to treat false positives, uncertainty, and missed scams as core design concerns. A useful safety system must explain its concerns, support legitimate members, and provide help when prevention fails.
Accomplishments we’re proud of
We developed an approach that connects risk assessment to a concrete member experience.
Our strongest design choice is adaptive verification: the number and depth of questions change as AMY learns more. This focuses attention where it is needed while reducing unnecessary interruptions.
We also made respectful communication and human review part of the core flow, rather than treating them as afterthoughts.
What’s next for AMY
We would refine the prototype against the challenge scenarios, test question clarity and accessibility, and evaluate both suspicious transfers and legitimate look-alikes.
A future pilot would measure:
- Unnecessary interruptions to legitimate payments.
- Time and questions needed to complete a safety check.
- Member understanding of warnings.
- Employee-review workload and turnaround time.
- Confirmed scam interventions and reported misses.
Before production, we would validate recipient-data sources, calibrate risk thresholds, establish privacy and retention rules, and confirm the bank’s authority and capabilities for payment holds.
Our goal is simple: ask the right questions at the right moment, and help members protect their money before it moves.
Built With
- framework
Log in or sign up for Devpost to join the conversation.