Explore/Free mini-course

AI in Treasury: Separating Real from Marketing →

FREE MINI-COURSE · 5 MODULES

I Built an AI Agent for Treasury. Here's How It Works.

A chatbot answers what you paste into it. An agent reads your systems, cross-references them, and hands you a root-cause analysis. This course walks through the actual architecture, tools, and cost of building one — plus a real example and the lessons that only surface once you try.

After this course, you will be able to

✓ Explain the difference between a chatbot and an agent in treasury terms
✓ Describe a data pipeline that sanitizes treasury data before it reaches an LLM API
✓ Name the five layers of an agent stack and what each one actually costs
✓ Read a real agent trace — plan, check, detect, impact, action — end to end
✓ Avoid the two mistakes people make first: skipping privacy, skipping tools

treasuryease.com

The difference isn't the model. It's who does the work.

With a chatbot, you are the middleware — you export, you paste, you copy the answer back out. With an agent, you type one sentence and it executes the steps itself.

Chatbot

1. You export bank data from the TMS
2. You pull the AR/AP report from ERP
3. You paste it into the LLM
4. Chatbot analyzes what you gave it
5. You copy the answer into an email
6. You update the systems manually

You are the middleware. 6 manual steps — you connect the dots.

AI agent

You type: "Why was Q1 forecast off?"

Agent autonomously

1. Reads your bank data
2. Reads your AR/AP aging report
3. Checks FX hedge coverage
4. Cross-references all 3 sources
5. Identifies 3 root causes + impact
6. Suggests AP correction
7. Recommends FX review

1 sentence typed. 7 steps executed.

Why this matters: the same LLM sits behind both. What separates them is whether it has tools to read your systems and act, or whether it's waiting for you to feed it text.

Your treasury data never reaches the LLM raw

Everything runs on localhost until it's sanitized. Only the cleaned, anonymized version ever leaves the machine.

Data sources

TMS — bank balances, payment dataERP — AR/AP, GL transactionsConfig files — credit limits, entity mapping

↓ localhost

Data ingestion

Parse · Normalize · Validate

Data sanitization

Remove entity names · Strip account numbers · Anonymize counterparties · Hash identifiers

↓ sanitized only

LLM API — OpenAI, Claude, or Azure

Receives only: numerical patterns, anonymized structures, generic categories — never raw IBANs or entity names.

↓

Output

Root cause analysis · Forecasts & alerts · Actionable recommendations

Module 2 action

List the 3 fields in your own treasury data that would need to be stripped or hashed before any of it could reach a public LLM API.

Five layers. You don't need all of them on day one.

Layer	Examples	Cost
LLM reasons about your data	OpenAI GPT-4o · Anthropic Claude · Azure OpenAI (EU residency)	$20–100/mo
Framework orchestrates the loop	LangChain · CrewAI · AutoGen · Semantic Kernel (.NET)	Open source
Tools actions the agent can take	Read CSV / MT940 / camt.053 · Query SQLite · Call APIs · Write Excel	Custom built
Data your existing systems	TMS (balances, payments) · ERP (AR/AP, GL) · Config files	Already have
Privacy PII removal before API calls	Microsoft Presidio · Custom anonymization · Hash IDs · Strip IBANs	Open source

You don't need all 5 layers on day 1. Start with LLM + Tools + your data. Add the framework and privacy layer as you scale.

"Why was Q1 forecast off by €1.2M?"

One question in. Here's the full agent trace that came back — nothing hidden, nothing summarized.

Agent — variance analysis

[PLAN] Comparing Q1 forecast vs actuals. Checking: AP timing, AR collections, FX hedges.

[CHECK] TMS → Q1 payment schedule: 847 transactions, €12.4M total outflows

[CHECK] ERP AR → Q1 receivables: 312 invoices, €8.9M expected inflows

[CHECK] ERP AP → supplier master data: checking payment term changes...

[DETECT] 3 suppliers changed terms NET60→NET30 in Feb. AP system not updated.

[IMPACT] €480K in outflows hit 30 days earlier than forecast assumed.

[DETECT] AR: Client_Group_B DSO increased from 45 to 52 days.

[IMPACT] 4 invoices >30d overdue. €520K delayed vs forecast.

[DETECT] FX: hedge coverage dropped to 62%. EUR/USD moved 3.2% unfavorably.

[IMPACT] Translation loss on unhedged USD receivables: €200K.

[TOTAL] Variance explained: €480K + €520K + €200K = €1.2M ✓

[ACTION] 1. Update 3 supplier terms in ERP (AP team).

[ACTION] 2. Escalate Client_Group_B to collections. 4 invoices, €520K.

[ACTION] 3. Review FX policy: increase hedge ratio from 62% to 85%.

Manually, this takes half a day, 4 spreadsheets, and 3 email threads. The agent didn't do anything you couldn't do — it just did all of it, at once, without you being the one carrying it between systems.

Four lessons that only show up once you build one

01Start with ONE question, not a platform

"Why is the forecast off?" — one question forces you to define the data sources, the reasoning, and the expected output. Everything else grows from there.

02The privacy layer is not optional

Treasury data has IBANs, counterparty names, entity info. You cannot send this raw to any LLM. Build sanitization first, before touching any AI logic — Presidio helps but needs heavy customization for financial data.

03The agent is only as good as the tools you give it

The LLM does the reasoning. But it needs tools to act: read CSV, query database, call API. Expect to spend more time building tools than writing prompts. No data access = chatbot with opinions.

04Corporates care about WHERE the data goes

Every conversation comes back to: who sees my data? The ability to swap LLMs (OpenAI, Claude, Azure, on-prem) and keep data local is not a feature — it's a requirement.

Module 5 action

Pick your own "one question" — the single recurring question you get asked that takes half a day to answer manually. That's where your first agent would start.

✓ Course complete