Real-time treasury does not mean allowing an AI model to move cash whenever it identifies a potential surplus or shortfall. A credible operating model starts with current and traceable data, separates prediction from authority, applies treasury policy before execution, and preserves a controlled path through settlement, reconciliation, and exception handling. The AI layer can make information more timely and recommendations more useful, but it should not collapse the controls that determine whether money is actually allowed to move.
What AI Actually Changes in Treasury Operations
AI is most useful where treasury teams need to interpret patterns across a large volume of changing data. Short-term cash forecasting can combine historical flows with known obligations and forward-looking business inputs. Classification models can categorize transactions or expected receipts. Anomaly detection can flag unusual payment behavior or large forecast deviations. Scenario models can show how changes in collections, payroll, foreign-exchange exposure, or debt obligations alter expected liquidity.
These functions are not the same as deterministic treasury rules. A rule such as “do not let an entity fall below its minimum operating balance” is a policy control, not AI. A model may estimate the future balance, but the rule determines whether a proposed transfer is permissible. That distinction is also consistent with the April 2026 U.S. interagency model-risk guidance, which excludes simple deterministic rule-based processes from its definition of a model.
The AI-Augmented Treasury Operating Model
A practical treasury workflow can be understood as a series of distinct control layers. Source systems first provide balances, invoices, receipts, payroll, debt schedules, tax obligations, planning data, and relevant market information. A data and integration layer then normalizes account, entity, currency, and timestamp information so that treasury is not comparing inconsistent records.
The AI and analytics layer uses that validated data to produce forecasts, classifications, anomaly alerts, or liquidity recommendations. A separate policy layer checks whether the proposed action fits minimum balances, counterparty limits, entity restrictions, permitted currencies, transaction thresholds, and approval requirements. Only after those controls pass should an authorized execution system create a payment or liquidity instruction.
The instruction then travels across an approved settlement rail, such as a bank payment network, payment provider, or, in specific designs, a programmable or tokenized rail. Confirmation is not the end of the process. Treasury and accounting still need to reconcile the result, resolve exceptions, and compare actual outcomes with the original forecast. Monitoring should then feed model-performance review and control testing.
Data Quality Determines the Value of the Forecast
Treasury models are only as useful as the inputs they receive. Common sources include the treasury management system, ERP, bank balances and statements, accounts payable, accounts receivable, payroll, tax schedules, debt facilities, planning data, and foreign-exchange information. Some organizations may also incorporate sales or order data when those inputs materially improve expected collections.
AFP identifies treasury systems, planning documents, centralized finance teams, business units, AP and AR, and automated bank feeds as common forecasting sources. SWIFT’s Instant Cash Reporting service also illustrates an important distinction: near-real-time bank-account visibility can be provided as a reporting capability without implying that every payment is simultaneously settled and reconciled.
Controls should therefore test data freshness, duplicate records, missing accounts, entity mapping, currency conversion, payment status, and feed availability before the model output is trusted. A stale bank API can make a technically sound forecast operationally wrong. A newly acquired subsidiary that is missing from historical data can make payroll or supplier outflows look smaller than they really are. When inputs are incomplete, the safe response may be to suspend automation and route the decision to manual review.
Where Human Approval Still Matters
AI augmentation can operate at several levels, and greater autonomy is not automatically better. At the first level, AI observes and reports: it identifies patterns, updates forecasts, and flags unusual activity. At the second level, AI recommends an action, while a treasury professional decides whether to proceed. At the third level, a validated recommendation can trigger rules-based execution only after predefined policy checks and approvals are satisfied. A fourth level, bounded autonomy, may allow narrowly defined low-risk actions to execute automatically inside hard limits.
The important distinction is between a model recommendation and authority to move money. Transaction initiators, approvers, policy administrators, model owners, technology administrators, and reconciliation teams may all have different roles. Kenson’s segregation-of-duties analysis provides the deeper control-design treatment. In treasury, the same principle helps prevent one user or system from changing a policy, approving a transaction, and executing it without independent checks.
Model Governance, Validation, and Auditability
An AI model used in treasury should have a defined purpose, an accountable owner, documented inputs and limitations, and performance measures tied to the decision it supports. Validation should test whether the model behaves as intended, while ongoing monitoring should identify deterioration, changing data patterns, or unexpected errors. Material changes to model logic or data should follow version and change-control procedures rather than being introduced silently.
NIST AI RMF 1.0 is a voluntary, cross-sector framework organized around Govern, Map, Measure, and Manage. It does not create a Treasury compliance rule, but it provides a useful structure for ownership, context, testing, monitoring, and response. The NIST AI RMF Playbook offers practical actions that organizations can adapt to their use case.
For banking organizations with material model risk, the Federal Reserve’s SR 26-2 revised model-risk guidance replaced SR 11-7 in April 2026. The guidance emphasizes risk-based governance, validation, monitoring, documentation, and effective challenge. It is not a universal corporate-treasury mandate, and the associated OCC guidance explicitly excludes simple deterministic rules from its model definition and places generative and agentic AI outside the formal scope of that particular guidance.
Auditability requires more than a transaction timestamp. A reviewer should be able to reconstruct the source data, model version, forecast or recommendation, policy result, approver identity, override reason, execution instruction, settlement outcome, reconciliation status, and any exception that followed. An immutable record of the final payment cannot prove that upstream model inputs or approvals were correct.
Where Blockchain or Programmable Payment Rails Fit
AI-augmented treasury does not require blockchain. Bank APIs, payment hubs, real-time reporting, and treasury management systems can support sophisticated cash visibility and controlled execution through conventional infrastructure. Tokenized or programmable rails are best treated as optional settlement mechanisms for use cases where their operating and legal characteristics fit the treasury requirement.
BIS Project Agorá demonstrates the potential for tokenized commercial-bank deposits and tokenized central-bank reserves to support atomic, multi-currency wholesale cross-border settlement on a shared programmable platform. The project also makes clear that these designs require technical, operational, governance, contractual, and legal work. Project Agorá is therefore useful as evidence of a possible future blockchain settlement infrastructure, not as proof that every corporate treasury should use one.
Stablecoins and tokenized deposits should not be treated as interchangeable forms of cash. BIS analysis published in August 2026 emphasizes that tokenized deposits remain commercial-bank liabilities, while stablecoins depend on different issuer, reserve, redemption, and market structures. Any stablecoin liquidity infrastructure therefore introduces its own custody, liquidity, counterparty, legal, and reconciliation questions.
For deeper treatment of digital-rail risk, see Kenson’s work on managing intraday exposure in always-on tokenized markets, programmable settlement finality, and blockchain in treasury and liquidity management. CPS 190 should remain centered on the treasury operating model rather than the rail itself.
Illustrative Use Case: Multi-Entity Cash Management
Consider an illustrative multinational group with several subsidiaries, accounts at multiple banks, three operating currencies, weekly payroll, daily supplier payments, debt-service obligations, and minimum liquidity buffers by entity. Bank data, ERP records, AP, AR, payroll, debt schedules, and planning inputs first enter a normalized treasury data layer.
The AI model produces one-day, seven-day, and short-term forecasts by entity and currency. It identifies a likely cash shortfall in one subsidiary and excess cash elsewhere. Before any transfer is proposed, deterministic policy checks test minimum balances, entity restrictions, counterparty exposure, currency limits, and transfer thresholds. The model then produces a recommendation that authorized treasury approvers can accept, reject, or override with a recorded reason.
If approved, the payment instruction goes through an approved bank or other permitted rail. Confirmation is matched back to the treasury system and accounting records. Forecast error, settlement exceptions, policy overrides, and reconciliation breaks are then recorded for model and process monitoring. The value of AI in this example is not autonomous cash movement. It is the faster identification and prioritization of a decision inside a controlled process.
Failure Handling and Safe Fallbacks
AI-augmented treasury should fail safely when data or infrastructure is uncertain. If a bank API is stale, automated recommendations that depend on that balance should be suspended or marked for manual review. If a forecast omits a newly acquired entity, completeness controls should catch the missing accounts before the forecast is used for execution. If model error rises after a change in customer-payment behavior, treasury should be able to revert to a simpler forecast or manual overlay while the model is recalibrated.
Execution failures need their own controls. A payment rail outage should trigger an alternate approved rail or a documented manual process rather than repeated blind retries. Duplicate-payment prevention should rely on transaction identifiers and idempotent processing where supported. Reconciliation breaks should stop further automated action when the system can no longer establish whether an instruction settled correctly.
Vendor and connectivity failures are also part of treasury resilience. Kenson’s third-party dependency risk framework provides the broader infrastructure perspective, while continuous verification and monitoring provide a deeper treatment of ongoing telemetry and control response. These issues can become material digital asset operational risk when treasury also uses tokenized or on-chain rails.
KPIs for AI-Augmented Treasury
- Forecast quality: forecast error, forecast bias, error by horizon, entity, and currency.
- Data and visibility: account coverage, source-data freshness, stale-feed incidents, and data-quality exceptions.
- Operations: manual-touch rate, exception volume, average exception-resolution time, and reconciliation breaks.
- Liquidity: buffer utilization, unexpected intraday shortfalls, and emergency funding events.
- Control: policy exceptions, override rate, blocked requests, approval turnaround, and segregation-of-duties exceptions.
- Model health: validation status, drift indicators, performance deterioration, and recalibration events.
- Execution: failed or returned payments, duplicate attempts, settlement time, and rail availability.
These metrics should not be assigned universal targets. The appropriate threshold depends on the institution’s risk tolerance, operating model, transaction profile, and forecast purpose. AFP’s 2025 Treasury Benchmarking Survey shows why the subject matters: cash management and forecasting remain leading treasury priorities, while cash and liquidity forecasting is among the most frequently cited challenges.
When AI-Augmented Treasury Is Not the Right Model
Some treasury environments need better data or process discipline more than they need AI. A sophisticated model may add little value when cash flows are simple and predictable, transaction volumes are low, reliable historical data is limited, material bank accounts sit outside centralized visibility, or existing feeds are too inconsistent to support a trustworthy forecast.
AI augmentation is also a poor fit when decision rights are unclear, policy controls are undocumented, model validation cannot be performed, exceptions are routinely handled outside formal systems, or integration costs exceed the expected operational benefit. In those environments, improving cash visibility, standardizing data, documenting approvals, and implementing deterministic controls may create more value than introducing a model.
AI-Augmented Treasury Implementation Checklist
Data
- Are all material entities, bank accounts, currencies, and expected cash flows represented?
- How fresh are source feeds, and what happens when a feed is late or incomplete?
Model
- What treasury decision does the model support, and what decisions is it not authorized to make?
- How is the model tested and validated before use?
- Which metrics reveal deterioration or drift, and who owns the response?
Authority and controls
- Who may act on a recommendation, and which actions require human approval?
- Which deterministic limits, counterparty restrictions, entity rules, and destination controls apply?
- Are model ownership, policy administration, transaction approval, and reconciliation appropriately separated?
Execution, audit, and recovery
- Which payment or settlement rails are approved for each type of transaction?
- How are duplicate execution and repeated retries prevented?
- Can an independent reviewer reconstruct the data, model output, policy result, approval, execution, settlement, and reconciliation outcome?
- What is the fallback if the model, data source, bank, API, vendor, or payment rail is unavailable?
- Which KPIs demonstrate that AI augmentation is actually improving treasury operations rather than simply increasing automation?
Using AI as a Controlled Treasury Layer
The strongest AI treasury model keeps several functions deliberately separate. Data describes the cash position. Models estimate what may happen next. Policy determines what is permissible. Authorized people or bounded systems decide what can execute. Payment rails move value. Settlement and reconciliation confirm what actually happened. Monitoring then tests whether the model and process still deserve to be trusted.
