AI for Treasury: Definition, Core Use Cases & Governance Requirements

Key Takeaway: AI for treasury is the application of agentic AI systems to corporate treasury workflows — cash forecasting, FX exposure monitoring, intercompany netting, real-time payment fraud detection, and liquidity scenario analysis — operating as decision-support layers under documented human oversight, with audit trails sized for DORA, payment-regulation, and EU AI Act expectations.

Definition

AI for treasury refers to AI agents and supervised models deployed inside the corporate treasury function to compress the data-plumbing and pattern-recognition work that historically consumed most of the treasurer's day. The agent reads from bank feeds, the treasury management system (TMS), the ERP, and market data providers; it produces forecasts, exposure reports, netting matrices, payment scores, and scenario results; the treasurer retains the judgment work — hedging decisions, counterparty approvals, regulatory filings, and material policy exceptions.

The boundary that defines AI for treasury, as distinct from broader AI in finance, is the regulatory overlay. Treasury intersects with payment regulation, market-abuse regulation when trading instruments are involved, and DORA's ICT and third-party risk requirements when bank connectivity, TMS platforms, or SaaS payment factories are in scope. The EU AI Act sits on top, applying Article 26 deployer obligations to every AI system used. The audit-trail expectation is therefore higher than for FP&A or AP/AR — every agent action that touches a payment instruction, an FX position, or an intercompany flow has to be reconstructible.

Core Use Cases

Five workflows are agent-ready in 2026 across most corporate treasuries:

  1. Cash forecasting. Rolling cash projection across entities, currencies, and accounts, integrating known commitments (AP scheduled payments, AR collections, debt service, payroll, tax) with statistical forecasts. The agent pulls position data from bank feeds, scheduled items from the ERP, applies seasonality and business drivers, and surfaces variance against the prior cycle.

  2. FX exposure monitoring. Continuous aggregation of operating, balance-sheet, and anticipated currency exposures, mapped against current hedge inventory in the TMS. The agent computes residual exposure by currency and tenor and flags positions that breach policy thresholds. The treasurer decides whether and how to hedge.

  3. Intercompany netting. Assembly of the netting matrix from each entity's sub-ledger, identification of counterparty mismatches (timing, FX restatement, missing entries, disputes), and drafting of net settlement instructions for human approval. Particularly audit-sensitive because intercompany eliminations land in consolidated financial statements.

  4. Real-time payment fraud detection. Anomaly scoring on outbound payment instructions in near real time, surfacing instructions that deviate from established patterns for human review before release. Counterparty history, amount distribution, currency, timing, originating user, and beneficiary geography all contribute to the score.

  5. Liquidity scenario analysis. Stress testing the base-case forecast under defined scenarios (customer payment delay, FX shock, facility drawdown, refinancing failure, counterparty default), identifying breach points against headroom thresholds, and surfacing the actions that would restore headroom.

What Stays Human

The boundary line is not a technology limitation — it is a fiduciary and policy boundary every regulated treasury team is expected to hold.

  • Hedging decisions — what to hedge, in what proportion, with what instrument, at what tenor.
  • Counterparty approvals — new banking, derivative, or beneficiary counterparties.
  • Regulatory filings — bank regulatory submissions, tax filings related to treasury transactions, statutory disclosures about treasury risk.
  • Material policy exceptions — when a flagged anomaly or breached threshold requires a deliberate exception, the exception is granted by a named human with documented authority.
  • Final payment release — no payment leaves the firm without a named human approval gate, regardless of the agent's score or counterparty history.

Regulatory Considerations

DORA (Digital Operational Resilience Act). Applies to financial entities in the EU from January 2025. Article 28-39 impose third-party risk requirements on AI vendors used in critical or important functions, including treasury. Non-financial corporates often face DORA-adjacent requirements through banking counterparties' own third-party frameworks.

EU AI Act. Article 26 deployer obligations apply regardless of risk classification — risk classification per workflow, human oversight design, monitoring, and audit trail are required for every AI system deployed. Most corporate treasury use cases sit at minimal-to-limited risk under the Act; the deployer obligations are still binding.

Payment regulation (PSD2/PSD3, instant-payment schemes, sanctions regimes). AI systems involved in payment release sit inside the payment regulator's scope of attention. The audit trail on flagged-but-released payments and on cleared-without-flag payments is the evidence regulators will request when investigating a fraud loss or a sanctions breach.

National banking supervision. Where the firm is itself a regulated financial entity, ECB, Banca d'Italia, BaFin, ACPR, or equivalent national supervisor expectations on model risk management extend to AI systems used in treasury. Document model versions, validation evidence, performance monitoring, and change control on the same standard as any other model in the regulated inventory.

Implementation Requirements

A treasury AI deployment that is defensible at audit and supervision time requires, at minimum:

  • Audit trail per agent run. Input snapshot, logic or model version applied, output produced, human reviewer or approver, timestamp. Retained for the longer of statutory audit retention, regulatory retention, document retention policy, and any litigation hold.
  • Risk classification per workflow. Documented rationale, not just the conclusion. Reviewed when use cases or systems change.
  • Human oversight at every consequential gate. No payment release without named approval. No hedge execution without policy alignment review. No counterparty addition without due diligence sign-off.
  • Credential isolation. Banking credentials, payment-system credentials, and signing keys do not enter the agent's context. The agent operates against pre-authorized integrations that hold credentials and expose only authorized operations.
  • Vendor governance pack. For each AI vendor in the treasury stack, the DORA Article 28-39 evidence (contractual resilience clauses, incident reporting timelines, ICT audit rights, sub-outsourcing register) and the AI Act Article 26 evidence (risk classification, oversight design, monitoring evidence, deployer-obligation register).

For the broader subfunction guidance and the implementation specifics, see AI for treasury & financial controlling. For the related controlling subfunction, see AI for financial controlling. For the function-level CFO guide, see AI for finance teams.

Related Terms