Inspiration
A member can authorize a payment and still be the victim of a scam. They may believe they are helping a family member or investing with someone they trust. Another warning is easy to dismiss when the story feels personal.
Our first hackathon concept focused on an AI assistant. Feedback pushed us to ask a harder question: Who defines what the AI is allowed to do?
That became Gatekeeper: AI guidance. Bank-defined guardrails. Safer payments.
What it does
Gatekeeper connects member support with employee-defined fraud policies. It intervenes before a payment is sent, explains the concern in plain language, and helps the member decide what to do next.
Our prototype follows two scenarios:
- Family emergency: Linda prepares an unusually large wire to a new recipient after an urgent request involving her grandson.
- Romance or investment: Michael’s payments increase over time before he switches to a wire transfer.
Members can see the payments behind a concern, answer contextual questions, request employee support, or continue after acknowledging the risk. Larger text controls make the experience easier to read.
Employees work from a Policy Studio and Activity & Cases workspace. They can inspect policy conditions, configure exemptions and payment-handling options, review member responses, group similar flags, and record follow-up actions.
How we built it
We built the prototype with React, JavaScript, and Vite, and deployed it through GitHub Actions to GitHub Pages.
Policies use a structured JSON-based domain-specific language (DSL). A deterministic rule engine checks explicit conditions such as a new recipient, an unusually large payment, or growing payments followed by a first wire.
The architectural principle is simple: AI can help explain and draft; approved rules define the boundaries.
For this prototype, policy generation uses bounded templates, chat responses are scripted, and cases and settings persist in browser storage. Payment holds, employee conversations, and frontline account flags are simulated. No real accounts or payments are connected.
Challenges we faced
Our biggest challenge was moving beyond a familiar fraud chatbot toward a system with a clearer operational purpose.
We also had to balance protection with autonomy. A suspicious pattern is not proof of fraud, so the experience needs understandable explanations, a legitimate payment path, and employee review.
Another challenge was reducing cognitive load. We shortened messages, replaced technical payment terminology, and separated brief explanations from deeper transaction evidence.
What we learned
We learned that the intervention matters as much as detection. A risk signal becomes useful only when a member understands it and has a practical next step.
We also learned that exceptions need boundaries. Exempting one transaction should not silently exempt an entire account. Our prototype distinguishes individual-case exemptions from limited future exemptions and records employee actions.
Most importantly, responsible AI requires more than a reassuring conversation. It needs explicit rules, accountable people, and a way to review mistakes.
Accomplishments that we’re proud of
- Connected policy setup, member intervention, and employee review in one working prototype.
- Made policy conditions readable and inspectable through the DSL.
- Showed transaction evidence alongside plain-language guidance.
- Added scoped exemptions, grouped flags, and activity logs.
- Built a mobile-friendly experience with adjustable text size.
- Tested rule matching, validation, and exemption boundaries.
What’s next for Gatekeeper
We would validate the workflow with credit-union staff and members, then explore integration with an existing banking app.
A pilot would begin in shadow mode, evaluating policies without interrupting payments. We would measure unnecessary interventions, member understanding, employee workload, and review turnaround before introducing payment controls.
The next technical step is a secure backend with authenticated employee access, versioned policy approvals, durable audit logs, and an LLM constrained by approved policy outputs. Gatekeeper’s goal is to make assistance adaptable while keeping consequential decisions governed by clear, reviewable rules.
Log in or sign up for Devpost to join the conversation.