BuzzMinter
← The Lab

Designing An Agentic Treasury System: Architecture Decisions

Architecture decisions when agents handle real money

Explore the real architecture behind agentic AI in treasury operations. This build log reveals what must happen before agents touch money, from reconciliation to audit trails.

The finance industry is having its agentic moment. CNN ran a piece this week on why finance is looking to agentic AI. Ripple shipped an XRP Ledger AI Starter Kit for agentic payments. Every treasury vendor and infrastructure provider is suddenly attaching the word "autonomous" to their roadmap.

We've been building in this space, so let me offer something more useful than another hype cycle: the actual architecture decisions you face when you try to put agents anywhere near money.

This is a build log. It documents how we're designing a treasury and financial-operations system on our shared multi-tenant foundation — where agents act on their own, where humans stay firmly in the loop, and how reconciliation, approvals and audit trails get structured so the whole thing is defensible. The interesting part of agentic finance isn't the demo where an agent moves money. It's everything that has to be true before you let it.

Why Treasury Is The Obvious Early Target — And The Hardest

Treasury operations look deceptively perfect for agents. The work is repetitive, rule-heavy, data-dense and deadline-driven:

  • Cash positioning across accounts and entities
  • Reconciliation of bank statements against the ledger
  • Payment preparation, batching and execution
  • FX exposure monitoring
  • Liquidity forecasting
  • Intercompany settlement

Most of this is pattern-matching and procedure-following — exactly what current models do well. That's why finance keeps showing up first in agentic roadmaps.

But treasury is also the place where a mistake is immediately and irreversibly expensive. A misclassified support ticket costs you an apology. A wrongly executed payment costs you real money, a broken bank relationship, and possibly a regulatory conversation. The asymmetry is brutal: the upside of automation is efficiency, the downside is catastrophic.

So the design problem isn't "can an agent do treasury work." It clearly can. The design problem is how do you capture the efficiency without inheriting the catastrophic downside. Every architecture decision below flows from that single tension.

The First Decision: Separate Cognition From Authority

The biggest mistake we see in agentic finance thinking is collapsing two things that must stay separate:

  1. The agent's ability to reason about a financial action
  2. The agent's authority to execute that action

In our architecture these are different layers with a hard boundary between them. Agents live in a reasoning and proposal layer. They read data, analyse it, draft actions, and explain their reasoning. They do not hold execution credentials. Execution lives in a separate authority layer that only acts on a validated, signed instruction — regardless of which agent or human produced it.

This sounds like a small distinction. It's the whole game.

When cognition and authority are fused, every model improvement and every prompt is a potential path to moving money. When they're separated, the agent can be wrong, confused, or even manipulated, and the worst it can do is produce a proposal that then has to pass through a deterministic gate it does not control. The blast radius of a bad agent collapses from "moved funds" to "suggested something that got rejected."

We treat the authority layer as boring on purpose. No model calls. No probabilistic logic. Just deterministic policy evaluation, signatures, and limits. The intelligence lives upstream; the safety lives in code that doesn't change its mind.

Mapping The Autonomy Spectrum

"Agentic" gets used as a binary — either the agent does it or it doesn't. In treasury that framing is useless. We map every operation onto an explicit autonomy spectrum with four levels, and each operation is assigned a level based on reversibility and value at risk.

Level 0 — Observe. The agent monitors and reports. It flags an FX position drifting past a threshold or a forecast variance. It takes no action. Used for anything where being wrong is fine but missing it is costly.

Level 1 — Propose. The agent prepares a complete action — a payment batch, a reconciliation match, a sweep — and presents it for human approval with full reasoning. Nothing executes without a person. This is where most genuinely useful treasury automation lives today.

Level 2 — Execute within bounds. The agent acts autonomously, but only inside hard, pre-authorised limits: known counterparties, amounts below a threshold, account-to-account moves that can't leave the organisation's control. Anything outside the box drops back to Level 1.

Level 3 — Full autonomy. Reserved for genuinely low-stakes, fully reversible operations. Internal reclassifications, draft generation, data enrichment.

The critical design rule: autonomy level is a property of the operation, not the agent. The same forecasting agent might be Level 0 for a new entity, Level 2 for routine internal sweeps under a limit, and Level 1 for everything else. You don't trust an agent. You trust a specific operation under specific conditions, and you encode those conditions explicitly.

This is also where we land on the human-in-the-loop debate. The honest answer is: humans stay in the loop wherever the action is irreversible and material, and step out wherever it's reversible or bounded. That line is the actual product. Getting it right per-operation, per-tenant, is most of the work.

Reconciliation: The Best Place To Start

If you're building agentic treasury, start with reconciliation. It's the highest-value, lowest-risk entry point, and it teaches the system the data it will later need to act on.

Reconciliation is fundamentally a matching problem: bank-reported transactions against expected ledger entries. Traditional rules engines handle the clean 80% and dump the messy 20% on a human — partial matches, timing differences, fees that shifted an amount by a few units, references that don't quite line up.

That messy 20% is where the agent earns its place. It's good at fuzzy matching, at reasoning about why two records that don't exactly match are probably the same event, and at explaining that reasoning. So our reconciliation agent operates at Level 1 to Level 2:

  • Confident matches above a confidence threshold are posted automatically (Level 2), with the reasoning logged.
  • Probable matches are proposed with an explanation for human confirmation (Level 1).
  • Anomalies — a transaction with no plausible counterpart — are escalated as exceptions, never silently absorbed.

The strategic value isn't just labour saved. Reconciliation is where the system builds a verified, ground-truth model of money movement. Every other agentic capability — forecasting, payments, liquidity — depends on that model being clean. You earn the right to do agentic payments by first doing agentic reconciliation well.

Approvals As A First-Class System, Not A Checkbox

In most software, approvals are an afterthought — a status field and a notification. In an agentic treasury system, the approval engine is core infrastructure, because it's the structure that lets you safely raise autonomy over time.

We model approvals as policy, not workflow. Instead of hard-coding "payments over X need two approvers," the policy layer evaluates each proposed action against a set of declarative rules per tenant:

  • Value thresholds (tiered, with different rules at each tier)
  • Counterparty status (known, new, flagged)
  • Originator (which agent or human, at which autonomy level)
  • Segregation-of-duties constraints — the proposer can never be the approver, and an agent's proposal still requires a human in the approval chain above a threshold
  • Temporal rules (a new counterparty has a cooling-off window before Level 2 applies)

Because this lives in the deterministic authority layer, an agent cannot argue its way past it. A model can be brilliant and persuasive in its reasoning, and the policy engine still rejects a payment to an unverified counterparty above the limit. Persuasiveness has no standing in the approval layer. Only policy does.

This is also what makes graduated autonomy safe. We don't flip an operation from Level 1 to Level 2 on a hunch. We watch the agent propose at Level 1 across hundreds of real cases, measure how often a human would have changed the proposal, and only raise autonomy when the approval-override rate falls below threshold and the bounded limits cap the downside. The approval system is both the safety gate and the measurement instrument that tells us when it's safe to relax the gate.

Audit Trails: Designed In, Not Bolted On

For treasury, the audit trail isn't compliance paperwork — it's the substrate that makes agentic action legitimate at all. If you can't fully explain why money moved, you can't let an agent move it, full stop.

So we capture, for every financially relevant action:

  • The complete input state the agent saw — the data, balances and context at decision time
  • The reasoning the agent produced, stored as a first-class artifact
  • The proposed action in structured form
  • Every policy evaluation the action passed through, with results
  • The approval chain — who or what approved, when, under which policy version
  • The execution record and its outcome

The principle is reconstructability. Any action, at any later date, must be replayable from the record alone — not "the agent decided to pay this invoice" but the full chain: this data, this reasoning, this policy version, this approver, this result. When a regulator, auditor, or your own CFO asks "why did this happen," the answer is a complete record, not a shrug at a black box.

This is non-negotiable and it's a constraint on the agents, not a feature on the side. An agent that can't produce inspectable reasoning doesn't get to operate above Level 0. The audit requirement actively shapes how we prompt and structure agents — reasoning has to be legible because it has to be logged.

Why This Belongs On A Shared Multi-Tenant Foundation

The natural objection: treasury is so sensitive, surely each deployment needs its own bespoke build. We see it the opposite way.

The hard parts of this system — identity, the authority/cognition separation, the policy-based approval engine, the audit substrate, the reconciliation primitives — are the same across every tenant. What differs is configuration: thresholds, counterparties, autonomy levels, approval chains, entity structure. That's exactly the shape that fits our shared platform foundation: build the dangerous, generic machinery once, harden it across every deployment, and express each organisation's treasury as policy on top.

This matters more in finance than anywhere else, because security and correctness compound with usage. A reconciliation edge case found in one tenant becomes a fix every tenant inherits. An approval-policy gap closed once closes everywhere. A bespoke per-client treasury build can never accumulate that hardening — it starts from zero every time, which in this domain is reckless.

It's the same operating principle behind everything we build: one shared foundation, multiple industry-specific systems. Treasury just makes the cost of getting the foundation wrong unusually vivid.

Where This Leaves Us

The agentic-finance narrative this week is mostly about capability — agents can move money, here's a starter kit. That's the easy part. The capability has been there for a while.

The build log reality is that the work is almost entirely in the constraints:

  • Separating cognition from authority so a wrong agent can't move money
  • Mapping autonomy per-operation rather than trusting an agent wholesale
  • Starting with reconciliation to earn a clean model of reality
  • Treating approvals as deterministic policy the agent can't override
  • Designing audit trails as the substrate, not the paperwork

None of that is glamorous. None of it demos well. But it's the difference between an agentic treasury system you can actually run a business on and a very expensive way to lose money quickly.

We're early in this build. The architecture above is what we're operating against, and we'll document what breaks as we push autonomy levels up under real conditions. That's the part the hype cycle never covers — and the only part that matters once there's real money in the loop.