What finance looks like when software becomes an actor
When software can act on money, not just record it, the hard questions stop being technical and become about permission and accountability.
For most of its history, financial software has been a ledger with a user interface. It records what people decided. Someone approves the payment, someone places the trade, and the software keeps track.
That’s changing. Software can now propose, decide and act: move funds when conditions are met, rebalance a portfolio, respond to a request at three in the morning. The question is no longer only whether the numbers are right. It’s who, or what, was allowed to act.
From records to decisions
Programmable money made the first step possible. Assets that can be held and moved by code mean the rules can live next to the value instead of in a separate process. Models add the second step: software that can read a situation and choose an action within those rules.
Put together, you get an actor. Not a person, not a tool, but something in between that holds permissions and uses them.
Permission is the product
When software acts, the interesting design problem is the permission model:
- Scope. What exactly may it do, with how much, and for how long?
- Limits. Hard caps that no instruction can override, enforced where the money lives, not in the prompt.
- Approval. Which actions need a human, and how that human sees enough context to say yes quickly and safely.
- Undo. Money often can’t be pulled back, so the checks have to happen before the action, not after.
Good financial infrastructure already thinks this way about people. Delegated access, spending limits and multi-party approval are old ideas. The new part is applying them to something that acts at machine speed and never gets tired.
Accountability doesn’t move
Regulation doesn’t care whether a person or a program made the call. Someone is still responsible. That’s healthy: it forces clear lines between what the software proposes and what an accountable party authorises.
The systems that work will make those lines visible. Every action traced to a permission, every permission traced to a person, and a log you could show an auditor without rewriting it first.
Open questions
- How much autonomy will customers actually want over their own money, once it’s on offer?
- What does a useful audit trail look like for a decision made by a model?
- Where should limits live: in the model, the application, or the asset itself?