Key takeaways
- The article, adapted from a CFO Insights podcast with Atlar CEO Joel Nordström and Guy Hutchinson, argues that treasury setups usually fall behind organizationally before they fail financially, because the banking setup has not kept up with the business.
- Typical warning signs include stale bank-portal users, processes that break if one person takes holiday, and requests to leave security tokens behind so someone else can send a payment.
- Nordström argues treasury will not simply fold into the ERP, and that building on a data lake is not a shortcut either: ERPs lack productized bank connections, aggregator feeds often prove unreliable at scale, and most bank-ERP integrations are still consultant-led projects that take months.
- Bank connectivity is treated as relationship work as well as engineering, because bank systems are legacy, poorly documented, and far from clean APIs, and a payments platform has to avoid duplicates, misroutes, and wrong amounts.
- Useful AI in treasury needs more than live balances: policy must be machine-readable so agents can reference the same rules the team uses, recommend actions against them, and surface results for human review.
Adapted from a conversation between Atlar CEO and co-founder Joel Nordström and Guy Hutchinson on the CFO Insights podcast, produced by Startup CFO.
The signs that a treasury setup hasn't kept pace tend to be organizational before they're financial. It's a point Joel and Guy returned to throughout their conversation on the CFO Insights podcast. The root cause tends to be the same: the banking setup hasn't kept up with the business. Fixing that starts with connectivity, and what you can build on top of it, AI included, depends on getting that layer right.
Where treasury setups fall behind
- The ghost user. A new CFO logs into a subsidiary's bank portal and finds users still active who left the company two years ago. No one noticed because no one owned the review.
- The holiday problem. Someone on the finance team can't take a proper holiday because a reporting process breaks without them.
- The credential handoff. Guy shared this one from his own time as a CFO: a CEO once asked him to leave his security tokens and login credentials behind before travelling, just in case a payment needed to go out. Every CFO knows this is a bad idea. The fact that it gets asked at all says something about the setup underneath.
By the time these patterns show up, as Joel put it, "it's for sure too late" to keep delaying the conversation.
Why connectivity can't be shortcut
With AI making it cheaper and faster to write code, a reasonable question is whether treasury will fold into the ERP, or whether a finance team could build their own setup on top of a data lake.
Neither path works, and for the same reason. ERPs don't offer productized, off-the-shelf connections to banks. Some integrate through aggregator platforms, but companies tend to find those connections aren't reliable enough as they scale. Most bank-ERP integrations are still handled by consultants: costly, bespoke projects that take months and need ongoing maintenance.
Building your own isn't much better. Bank systems are legacy, poorly documented, and nowhere near clean APIs. Getting reliable access takes sustained relationship work, not just engineering time. And the platform handling payments has to be demonstrably trustworthy: no duplicates, no misroutes, and no wrong amounts. That's not the kind of problem you solve by generating code faster.
Joel compared this to AP automation, where scanning an invoice, matching it to a PO, and posting it to the GL is something AI can handle end-to-end. That work fits inside the ERP. Treasury is different because the hard part isn't necessarily the software; it's the connections and the reliability of what runs behind them.
Policy is what makes AI in treasury useful
Reliable connectivity gives AI something to work with: real-time bank balances, live ERP data. But data alone isn't sufficient. Every treasury runs on its own mix of banks, ERPs, payment terms, and risk appetites, and a model working only from transactional data will produce generic output that doesn't fit the business.
Every treasurer already works against a policy. Sometimes formal and board-approved, sometimes an informal agreement between the CFO and the person closest to cash. "You're not freestyling," as Joel put it.
Make that policy machine-readable and the AI doesn't just get more relevant. It becomes accountable to the same rules as the team. An agent can reference the policy when recommending actions, and a reviewer can validate its reasoning against the same document. This is the principle behind Atlar's AI agents: they run on real-time financial data, reference treasury policies when executing tasks, and surface results for human review.
For teams with a treasurer, that clears routine work off their desk. For teams without one, it raises what the finance function can do with the people already in place.
See it in action
If you're interested in what an AI-native treasury platform looks like in practice, request a demo or get in touch and we'll show you around.
_NEF-EDIT.avif)
