Inspiration
Managing personal finances is still mostly manual. People say things like “I should save more” or “I want to spend less on X,” but turning that into consistent behavior is difficult.
At the same time, the rise of multi-modal AI and agentic systems has made the landscape even more complex. We now have systems that can interpret text, images, and audio — and increasingly, act on behalf of users. But this creates a new problem: once an agent can take actions, how do you make those actions understandable, predictable, and safe?
That tension inspired Bunql.
Instead of letting agents act directly, Bunql introduces a layer of structure: a DSL that turns intent into explicit, inspectable rules. It acts as a safety net — something you can reason about, audit, trust, and interpret — even when the inputs come from messy, multi-modal AI systems.
That’s the idea behind Bunql: make money programmable and guardrails transparent.
What it does
Bunql is a domain-specific language (DSL) for automating personal finances.
Users write simple rules like:
when income then
transfer 30% to "savings"
invest 10%
warn "allocations done"
when amount > 2000 and merchant = "Amazon" then
warn "large purchase"
These rules are evaluated against real-world events (transactions, payments, etc.), and produce concrete execution plans.
Crucially, Bunql is designed to sit between AI systems and financial actions:
- LLMs can generate or refine rules
- speech-to-text can create rules from voice
- OCR can extract structured data from receipts
But nothing executes unless it passes through the DSL.
How we built it
We built Bunql as a pipeline:
- A custom grammar using Lark
- An AST transformer to turn scripts into structured data
- A planner that evaluates conditions and produces execution plans
- An executor that performs actions via the bunq API
On the backend we used FastAPI and PostgreSQL. Scripts are stored in the database and executed when events arrive.
We integrated the bunq API end-to-end, including:
- installation
- device registration
- session creation
- signed requests
- webhook callbacks
The full flow looks like:
bunq → webhook → Bunql engine → planner → executor → bunq API
Challenges we ran into
Designing and implementing a DSL is hard.
Accomplishments that we're proud of
Designing and implementing a DSL is hard and we got part of the way there.
What we learned
Designing and implementing a DSL is hard and we now know how to get part of the way there.
What's next for Bunql -- A DSL for Automating Your Money
Next we will push things further into agentic + multi-modal integration.
Built With
- amazon-web-services
- bunq
- claude
- fastapi
- lark
- postgresql
- python
- typescript
Log in or sign up for Devpost to join the conversation.