Building the Agentic Treasury

What is an agentic treasury?

An agentic treasury is a corporate treasury function in which specialized AI agents continuously analyze cash, liquidity and payment data and produce grounded, evidence-backed recommendations, while a human treasurer keeps decision authority, every recommendation is filtered through policy enforced as code, and every action is written to an immutable audit trail.

It is not an autonomous treasury. The agents propose, orchestration policy-checks the options, a human authorizes, and only then does execution happen.

In this guide the agents are Maria (forecasting and risk), Alejandro (liquidity and investment) and Sam (transaction and operations), coordinated by an orchestration layer that routes every request, enforces policy as code, and logs it. The governing sequence is governance first, intelligence second, automation last.

00The build philosophy

The companion video shows Lisa asking questions and three agents (Maria, Alejandro, and Sam) answering in seconds. It looks like a conversation. It is not. It is infrastructure.

This guide deconstructs that infrastructure so you can build an agentic treasury yourself. Before the components, one principle governs every decision that follows:

This is not a chatbot bolted onto a treasury management system. It is a structured, policy-governed architecture that embeds intelligence into institutional infrastructure. Remove orchestration and governance collapses. Remove data grounding and recommendations become unreliable. Remove human authority and institutional accountability disappears. Each layer depends on the others, and the system is deliberately designed to fail safely: when uncertainty arises, control escalates to a human.

01The five-layer architecture

Every request in the system flows through five layers. Each has a distinct responsibility, and together they form a treasury operating model that is both intelligent and institutionally controlled.

02The orchestration layer: the institutional control plane

In the video Lisa appears to talk directly to the agents. In reality, she never does. Every request flows through an orchestration layer that is invisible to the user but essential to the system's integrity. This is the operating system of the agentic treasury. Build it first.

The five core functions

• Intent routing: decides which agent(s) respond and what data is required. "Show me next quarter's forecast" → Maria; "How do we cover this shortfall?" → Alejandro; "Has the Brazil payment arrived?" → Sam; "What's our liquidity across all entities?" → Maria + Sam, coordinated.
• Workflow coordination: sequences agent interactions, combines outputs, resolves conflicts, maintains context across multi-turn workflows.
• Policy enforcement: applies liquidity buffers, exposure limits, approval hierarchies, compliance and operational controls as code. Non-compliant options are filtered out before Lisa ever sees them.
• Human-in-the-loop control: inserts mandatory approvals at high-value payments, credit usage, risk escalations, policy overrides, and new counterparties.
• Audit & explainability: logs inputs, data sources, agents invoked, policies applied, human approvals, and outcomes. Immutable and cryptographically signed.

Implementation stack: orchestration layer

03Agentic RAG: how intelligence is grounded

Large language models reason well, but on their own they carry two risks that are unacceptable in institutional treasury: they rely on training memory that may be stale, and they can produce confident-sounding answers with no verifiable grounding. The agents solve this with Agentic Retrieval-Augmented Generation.

Traditional RAG retrieves once and generates. Agentic RAG is active: the agent decides what information is required, which sources to query and in what order, whether it has enough context, and how to reconcile conflicting data, validating everything against policy before responding.

The difference in practice

Implementation stack: Agentic RAG components

Data sources the agents ground against

The LLM never guesses. It reasons over retrieved evidence. Every statement traces back to a specific data source with a timestamp.

04Building Maria: Forecasting & Risk

Maria generates predictive cash-flow models, runs scenario simulations, and identifies liquidity gaps weeks in advance. She is the Agentic RAG pattern in action. When Lisa asks "show me our projected cash flow for the next 90 days," Maria does not answer from memory. She executes a grounded workflow:

1. Intent classification: orchestration identifies a forecasting request and routes to Maria.
2. Data planning: Maria determines required sources: ERP (payables/receivables), TMS (cash positions), warehouse (historical patterns), market feeds (FX/rates), policy repository (buffer requirements).
3. Retrieval orchestration: pulls upcoming obligations, current balances, timing patterns, FX forecasts, and applicable policies.
4. Context assembly: retrieved data is normalized for cross-system consistency and time-aligned to the 90-day horizon.
5. LLM reasoning: projects daily cash positions, identifies inflows/outflows, calculates net positions by week, accounts for currency translation.
6. Risk evaluation: scans for projected shortfalls, policy-buffer violations, concentration risk, and timing mismatches.
7. Response generation: delivers a structured forecast with visual projection, narrative drivers, flagged risk periods, and recommended actions.

Deploy Maria first: low operational risk, high strategic value, immediate visibility. She proves the governance model on the lowest-risk use case.

05Building Alejandro: Liquidity Optimization

Maria understands what might happen; Alejandro determines what to do about it. When a shortfall is detected, orchestration activates Alejandro to evaluate funding options within institutional constraints. He doesn't return a single answer. He returns an optimized decision framework.

How Alejandro thinks: a multi-step optimization workflow

1. Context intake: forecasted shortfall (amount, timing, duration), root cause, risk indicators, current positioning, strategic context.
2. Data retrieval: investment accounts, cash pools, credit facilities, intercompany balances, supplier terms; plus external rate curves, FX projections, funding-market conditions.
3. Scenario modeling: simulates funding strategies in parallel (reallocate idle cash, draw a revolver, delay payments within policy, intercompany transfer, liquidate short-term investments), each with quantified cost/liquidity/risk trade-offs.
4. Policy filtering: applies minimum buffers, DPO limits, credit-usage thresholds, exposure and counterparty limits. Non-compliant options are removed or flagged for exception approval.
5. Recommendation generation: returns only policy-compliant strategies, ranked by a composite score weighing cost, risk, and strategic alignment, with rationale and an alternative.

Implementation stack: Alejandro's workflow

Add Alejandro only after forecasting is trusted. Optimization without governance creates risk. It works only when policy is enforced automatically, recommendations stay transparent, and humans authorize execution.

06Building Sam: Real-Time Transaction Intelligence

Maria forecasts risk. Alejandro optimizes liquidity. Sam ensures execution happens safely. He is the operational intelligence layer connecting treasury decisions to real-time payment reality, answering "Has the payment arrived? Can we proceed?" in seconds instead of the 30–60 minutes of manual portal-checking it used to take.

How Sam works

• Real-time status retrieval: queries bank APIs, SWIFT gpi Tracker, instant-payment rails (FedNow, PIX, SEPA Instant), ACH networks, and internal ledgers simultaneously.
• Reconciliation intelligence: compares expected flows (from TMS) against actual settlement data; catches duplicate payments, missing confirmations, delays, and exceptions.
• Event monitoring: event-driven, not batch: status changes (PAYMENT_INITIATED → INTERMEDIARY_CLEARED → SETTLEMENT_PENDING → PAYMENT_SETTLED) trigger instant notifications.
• Coordination with other agents, if a payment is delayed, Sam alerts orchestration, which automatically re-engages Alejandro to model contingency options; Lisa receives one unified update, not fragmented alerts.
• Human confirmation: once funds settle, Sam confirms with full context; execution proceeds only after Lisa authorizes.

Implementation stack: Sam's technology components

Add Sam after governance has matured, transaction intelligence introduces the most live integrations and benefits from a proven control plane.

07Bank connectivity: what banks provide & how to connect (API + MCP)

The agents are only as good as their connection to the banks. Maria's forecasts, Alejandro's funding options, and Sam's settlement checks all depend on live data pulled from, and instructions pushed to, the institution's banking partners. This section makes explicit what banks expose and how the platform connects to it: through bank APIs, established treasury channels, and, increasingly, MCP servers that make those capabilities callable by agents under governance.

What banks provide

Banks don't expose "an API". They expose a set of distinct capabilities, most standardized on ISO 20022 message types. These are the ones that matter for an agentic treasury:

How the connection is established

The same capability can arrive over different channels. Most institutions use more than one: real-time APIs for status and instant payments, host-to-host or a TMS for bulk statements and batch disbursement.

Where MCP fits: the agent-native layer

MCP does not replace any of the above. Under the hood the connection is still a bank REST API, SWIFT, or a TMS connector. What an MCP server does is expose those capabilities to agents as typed, governed tools. Instead of Sam holding raw bank credentials and hand-rolling HTTP calls, the platform runs an MCP server that wraps the bank/SWIFT/TMS endpoints as named tools: get_balances, get_payment_status, initiate_payment, each with a defined schema, scoped authentication, and a full audit record of every call.

This maps cleanly onto the architecture already in this guide: the MCP layer sits between the Agent Intelligence layer and the bank/data systems, and every tool call flows through the same orchestration, policy, and audit controls as everything else.

Whether you connect via direct bank APIs, a TMS, or an MCP server, the governance rule is identical: agents read freely within policy; agents never execute a payment without a human authorizing it.

08Human-in-the-loop & governance

The agents produce insights, recommendations, and operational updates. Yet one principle never changes: they never execute decisions independently. AI accelerates analysis; only humans carry accountability. Every high-impact action requires Lisa's approval. This is not a limitation, it is the foundation of institutional trust.

Where human approval appears

Liquidity adjustments, risk escalations, and high-value payments each trigger an authorization gate. When Alejandro recommends executing a $5M supplier payment that exceeds the treasurer's limit, orchestration routes it for CFO approval with full context and explainability attached, before execution proceeds.

Implementation stack: human governance controls

09The explainability console

In institutional finance, a recommendation is not enough. Leaders must be able to answer: why was this recommendation made? what data was used? which assumptions applied? what alternatives were considered? which policies influenced the outcome? Without explainability, AI becomes a black box, and in regulated environments, black boxes fail governance. The explainability console is not a separate agent; it is a transparency layer integrated into orchestration.

For every recommendation, it surfaces data traceability (systems accessed, timestamps), a reasoning summary (why this option, key trade-offs), policy context (rules applied, constraints that removed alternatives), scenario comparison (paths considered), and approval history (decisions, overrides, timestamped authorizations).

Implementation stack: explainability components

Lisa is not asked to trust the system blindly. She is empowered to understand it.

10End-to-end operational flow

Assembled, the pieces operate as a continuous treasury workflow that runs in the background of Lisa's day. The goal is not automation of tasks. It is orchestration of intelligence.

11Deployment roadmap

The architecture is not deployed all at once. Successful institutions implement incrementally, prioritizing governance and operational stability over automation speed. The goal is not to "install AI". It is to evolve treasury into an intelligent operating model.

Frequently asked questions

What is an agentic treasury?

An agentic treasury is a treasury function in which specialized AI agents analyze cash, liquidity and payment data and produce grounded recommendations, while a human treasurer retains decision authority and every action is policy-checked and logged to an immutable audit trail.

How do you build an agentic treasury?

In six phases, governance first: build the orchestration and governance control plane, connect enterprise and market data, deploy the forecasting agent (Maria), add liquidity optimization (Alejandro), add transaction intelligence (Sam), then run the agents as a coordinated system. Governance first, intelligence second, automation last.

What technology stack does an agentic treasury use?

Workflow engines such as Temporal, Camunda or AWS Step Functions; agent routing with LangGraph or LangChain; policy enforcement with Open Policy Agent; reasoning with GPT-4, Claude or Gemini grounded by vector databases such as Pinecone, Weaviate, FAISS or Chroma; enterprise data from ERP, TMS and warehouse systems; event streaming with Kafka or EventBridge; and audit logging with Splunk, Datadog or the ELK stack.

Is an agentic treasury autonomous?

No. Agents read data freely within policy, but writes and payments are gated: the agent proposes, orchestration policy-checks, a human authorizes, and only then does execution happen.

How do AI treasury agents connect to banks?

Through the capabilities banks already expose: ISO 20022 reporting (camt.052, camt.053), payment initiation (pain.001), status and advice (pain.002, camt.054), SWIFT gpi tracking, and instant rails such as FedNow, RTP, SEPA Instant and PIX, delivered over bank or Open Banking REST APIs, host-to-host and EBICS, SWIFT, or TMS connectors. An MCP server can expose these as typed, governed tools, with read-only tools callable by agents and write tools behind human approval.