Scamurai

• 

Inspiration

A message arrives from someone who says they're a family member. They need money right away, so you send it. Hours later you find out it was a scam, and the payment may be hard or impossible to get back.

We built SCAMurai around the gap between deciding to pay and actually sending the money. In that window, a banking app can notice warning signs, explain them in plain language, and give the member a chance to get help first.

What it does

SCAMurai is an AI-assisted fraud intervention layer for a simulated Sound Credit Union payment flow. When a member starts a transaction, two models check it at the same time. An orchestrator combines their results into a risk score and decides what happens before the payment goes out.

Model 1: User Behavioural Profiler

This model checks whether a payment looks different from the member's usual activity. It looks at the amount compared with past payments, whether the payee is new, unusual payment methods, how often the member is sending money, and recent account changes. An unusual payment raises the score. On its own, it doesn't decide that a payment is fraud.

Model 2: Threat Detective Agent

This model looks at the recipient side of the payment. It watches for repeated suspicious payment patterns and changes in how a recipient account is used. It also pulls current scam information from government sources, including FTC consumer scam alerts and complaint data, FBI IC3 advisories, and alerts from regulators. It shows the member the alerts that match their payment, so they can see which known scam tactic it resembles.

Orchestrator and risk score

The orchestrator combines both model outputs into a risk score between 0 and 1 and routes the transaction:

• Low (below 0.6): the payment is sent.
• Medium (0.6 to 0.9): the member enters KERNEL Mode for verification.
• High (above 0.9): the member goes straight to E-sign release.

KERNEL Mode (medium risk)

KERNEL Mode shows the reasons from both models, and the member picks one way to verify the payment:

• Family 2FA: a trusted contact the member chose in advance gets a notification with the payment details and confirms whether the payment looks legitimate. Their approval counts as the second authentication factor.
• SCU Verify: a credit union employee reviews the payment details and the warning signals.

Either check ends in one decision. If the payment isn't a scam, it's sent. If it is flagged as a scam, the member goes to E-sign release.

E-sign release

High-risk payments come here directly, and so do medium-risk payments flagged as scams during verification. The member sees the warning signals from both models and signs an electronic risk acknowledgment to release the payment. The signature records that the member saw the warnings and chose to go ahead.

How we built it

We kept detection apart from the actions that members and employees take. The backend runs on Python and FastAPI and handles payment review, orchestration, case handling, and state changes. There are three front ends: a member view for warnings, verification, and e-sign release; an employee dashboard for SCU verification; and a trusted-contact view for Family 2FA.

The challenge organizers provided synthetic member and payment-event data. We used it to build and test behavioral features and payment scenarios, so we never touched real member accounts. The User Behavioural Profiler uses Isolation Forest for anomaly detection. The Threat Detective Agent combines recipient-side features with scam data from government websites.

Challenges we ran into

Legitimate payments can look unusual. A large transfer to a new recipient may be completely legitimate. We needed a path that treats real members with respect and still flags risky activity, so we tested legitimate-but-unusual cases as carefully as scam cases.

Matching government alerts to a single payment. Government sources describe scam tactics and trends. They don't identify individual recipients. We had to match a payment to a published tactic without calling the recipient a scammer because of a loose match.

A score by itself doesn't tell members what to do. We wrote explanations like "This amount is much higher than your usual payments" and "The recipient is new, and this payment pattern matches a scam the FTC reported recently."

Respecting member choice. Members keep control of their own money. E-sign release lets a member go ahead after seeing every warning, and it keeps a record that they were told.

Turning a score into an action. Each score range leads to a specific next step: send the payment, verify through Family 2FA or SCU, or go to E-sign release.

What we learned

Classifying transactions turned out to be a small part of preventing fraud. Whether a warning helps depends on when it appears, how clearly it explains itself, and how easily the member can get help. We also learned to keep four things separate: anomaly scores, recipient risk indicators, public scam trends, and confirmed fraud labels.

What's next for SCAMurai

• Flag unusually large ATM withdrawals, since scammers often push victims to pull out cash.
• Measure false positives and missed scams, then tune the risk thresholds.
• Track how quickly members can clear a legitimate payment.
• Improve the employee workflow and make the warnings more accessible.

Built With

• ai
• anomaly
• artificial
• behavioral
• cybersecurity
• data
• detection
• explainable
• fastapi
• financial
• forest
• fraud
• integration
• isolation
• machine
• predictive
• prevention
• python
• random
• real-time
• risk
• science
• scikit-learn
• scoring
• technology