Fig. 03 · Agentic banking with a policy engine

Budera

A banking assistant that reads a customer's accounts and prepares around 30 kinds of operations, where every write passes a deterministic policy engine and a password-confirmed approval before it touches the ledger.

Y Combinator · top 10%
Role
Cofounder & sole engineer
Team
2 cofounders
When
2024 – 2026
Stack
Laravel 12, Inertia + React, Laravel AI SDK, Fortify 2FA, spatie/permission, Next.js
Links
Private repo

01The problem

Menu-heavy banking apps make wires, FX, loan drawdowns and disputes painful. Smaller banks can't build safe conversational banking in-house, and a plain chatbot can't be trusted to move money.

02How it evolved

2 versions

  1. v1

    Operations agents

    v1 was a 17-agent operations platform for founders and SMEs.

  2. Now

    Agentic banking

    v2 rebuilt the idea as banking infrastructure with policy at the centre.

03How it works

6 steps

  1. 01 · AI proposes

    The assistant reads

    About 25 side-effect-free read tools. It must call them before stating any balance, ID or amount.

  2. 02 · AI proposes

    It drafts an intent

    About 30 intent tools (wires, FX, card freezes, loan drawdowns, disputes) that only return a JSON payload. They can't write anything.

  3. 03 · Rules decide

    The policy engine evaluates

    Allow-list, required fields, role gates, velocity, amount thresholds, risk triggers, step-up and dual control produce one of five decisions: allow, step up, dual approval, hold or deny.

  4. 04 · Person approves

    The customer re-enters their password

    For every write. Dual-control intents also need a supervisor, and held intents can't be self-approved.

  5. 05 · Rules decide

    A deterministic executor writes

    Only the executor touches the ledger. Every step lands in an audit log, and the outcome goes back into the chat.

  6. 06 · Person approves

    Ops and compliance review

    Anything that isn't allowed opens a compliance case for fraud, payments or compliance roles.

  • AI proposes
  • Rules decide
  • Person approves
  • System moves data

04Hard problems

3 of them
01

Letting an LLM bank without letting it move money

Reading and proposing are tools; executing is not. Execution lives in separate code that runs only after policy evaluation and a password-confirmed approval.

02

Bank risk policy as configuration

One config file defines decisions, roles, allow-lists, required fields, velocity, thresholds, step-up and dual control. Every decision stores the checks it ran and the rules it triggered, so compliance can see why.

03

Brute force on approvals

Failed password attempts feed a velocity rule that holds further intents, and held or dual-control intents can never be approved by the person who made them.

05By the numbers

banking operation types behind one policy engine
~30
possible policy decisions, each with its triggered rules stored
5
roles, from customer to read-only auditor
7
automated tests
231

06What I'd do differently

The executor writes to Budera's own ledger tables. I'd build one real core-banking adapter (idempotency, reconciliation, timeouts) before widening to 30 operation types, because that's where most of the integration risk lives.
Next · Fig. 04CostrymMulti-agent cost cutting for SMEs