AI Treasury Risk: Cyber Threats, Assessment & Controls

Key Takeaways

• AI creates real efficiency gains for treasury functions, but it also introduces risk categories many finance teams haven't formally assessed before.
• AI treasury risk goes beyond cybersecurity — it includes model, data, vendor, privacy, operational, and resilience risk.
• Financial institutions need a current inventory of every AI use case, model, and vendor dependency before they can meaningfully manage the risk.
• A proper AI treasury risk assessment examines the full AI lifecycle, not just the moment of deployment.
• The Treasury-backed FS AI RMF gives financial institutions sector-specific, voluntary guidance built around 230 control objectives.
• Third-party AI vendors and foundation models require ongoing due diligence, not a one-time review at contract signing.
• Sensitive financial data used in or by AI systems needs its own privacy and security controls.
• Human oversight, continuous monitoring, documented evidence, and incident response remain essential regardless of how capable the underlying model is.

What Is AI Treasury Risk?

AI treasury risk is the combined financial, operational, cybersecurity, privacy, model, vendor, and compliance risk created when artificial intelligence is used in treasury and broader financial operations. It shows up wherever AI touches cash forecasting, liquidity management, payment operations, fraud detection, FX exposure management, financial analytics, or the treasury management systems (TMS) that tie these functions together.

The risk isn't limited to the AI model itself. It extends to the data feeding the model, the third-party vendors and APIs delivering it, the humans overseeing its output, and the resilience of the process if the AI is wrong, unavailable, or compromised. A treasury team using an AI-assisted cash-forecasting tool, for example, carries model risk (is the forecast accurate?), AI data risk (is the input data clean and appropriately protected?), vendor risk (who operates the model, and where does the data go?), and operational risk (what happens if the tool is unavailable during a liquidity event?) — all at once.

What Happened: Treasury's Warning About AI Cyber Threats

In March 2024, Treasury's Office of Cybersecurity and Critical Infrastructure Protection (OCCIP) published Managing Artificial Intelligence-Specific Cybersecurity Risks in the Financial Services Sector, produced under Executive Order 14110. The report described how AI is simultaneously expanding financial institutions' attack surface and giving defenders new detection tools, and it flagged a widening "capability gap" between large institutions with dedicated AI security expertise and smaller institutions without it. It also called for common terminology across the sector — a gap Treasury would later address directly.

That 2024 report is distinct from a separate, later Treasury initiative. In February 2026, Treasury announced the conclusion of a public-private effort under the Artificial Intelligence Executive Oversight Group (AIEOG) — a partnership between the Financial and Banking Information Infrastructure Committee (FBIIC) and the Financial Services Sector Coordinating Council (FSSCC) — to release six AI risk-management resources for the sector over the course of the month. The first two, released February 19, 2026, were a shared AI Lexicon and the Financial Services AI Risk Management Framework (FS AI RMF), discussed in detail below.

Read together, the two actions tell a consistent story: Treasury first identified AI-driven cybersecurity and fraud risk as a sector-wide concern, then followed up with a structured, sector-specific framework institutions can use to actually manage that risk. They are not the same announcement, and institutions should not treat the 2024 warning and the 2026 framework as interchangeable.

What Is the Financial Services AI Risk Management Framework?

The Financial Services AI Risk Management Framework (FS AI RMF) is a voluntary, industry-informed AI risk-management framework built specifically for financial institutions. It was developed through the AIEOG process, with the Cyber Risk Institute (CRI) leading framework development in coordination with the FSSCC and input from more than 100 financial institutions and regulators.

The FS AI RMF is structurally aligned with the NIST AI Risk Management Framework's four functions — Govern, Map, Measure, and Manage — but translates them into financial-services-specific guidance. Its stated purposes include helping institutions:

• Identify and evaluate their AI use cases
• Manage AI risk across the full system lifecycle, from design through retirement
• Establish clear accountability for AI-related decisions
• Improve transparency and explainability where AI affects customers or financial outcomes
• Strengthen operational resilience against AI-related disruption
• Support supervisory and audit-ready governance

Institutions should treat the FS AI RMF as structured, voluntary guidance — not a binding regulation. It is not itself a law, and Treasury has not stated that every financial institution must adopt every element of it. Its practical influence, however, is likely to grow as examiners, auditors, and counterparties increasingly reference it as a shared benchmark for what "reasonable" AI governance looks like in financial services.

What Are the 230 AI Risk Control Objectives?

The FS AI RMF's centerpiece is a matrix of 230 control objectives spanning governance, data management, model development and validation, monitoring, cybersecurity, third-party risk, human oversight, and consumer protection. Rather than a single one-size-fits-all checklist, the controls are organized by AI adoption stage, so an institution just beginning to formalize AI governance and one running dozens of production AI systems can both find controls appropriate to where they actually are.

In practice, the control-objective structure matters more than the number itself. It gives a treasury or risk team a way to answer three questions for any given AI use case: which controls are relevant to this specific system and its risk level, what evidence would demonstrate that control is operating, and who owns making sure it does. Institutions are not expected to implement all 230 objectives uniformly — applicability depends on the institution's size, AI maturity, use cases, and risk profile. Treated this way, the framework functions less like a compliance checkbox exercise and more like a shared vocabulary for prioritizing AI risk work.

What Is an AI Treasury Risk Assessment?

An AI treasury risk assessment is a structured evaluation of how AI is used within treasury and finance operations, covering the business criticality of each use case, the sensitivity of the data involved, the risk profile of the model and its vendor, and the controls in place across cybersecurity, privacy, human oversight, and operational resilience.

A complete assessment typically evaluates:

• The AI use case and its business criticality
• Data sensitivity and data flows
• Model risk (accuracy, explainability, drift)
• Cybersecurity exposure
• Vendor and third-party risk
• Privacy and regulatory considerations
• Human oversight and escalation paths
• Monitoring and alerting coverage
• Operational resilience and fallback procedures
• Incident response readiness

Where Is AI Used in Treasury?

Cash Forecasting

AI can improve forecast accuracy by identifying patterns across historical cash flows. The risk: forecasts that look confident but are built on incomplete or stale data can lead to real liquidity misjudgments if not validated.

Liquidity Management

AI-assisted liquidity models can surface funding gaps earlier. The risk is over-reliance on a single model during stressed conditions the model wasn't trained on.

FX Exposure Management

AI can help flag unusual currency exposure or suggest hedging adjustments. The risk is opaque model logic that's hard for a treasurer to explain to auditors or the board.

Payments

AI increasingly supports payment screening and anomaly detection. The risk is that the same automation, if compromised, can be turned toward approving fraudulent payments faster than a human reviewer would.

Fraud Detection

AI-based fraud detection can catch patterns humans miss. The risk is false positives disrupting legitimate payments, or false negatives from adversarially crafted fraud designed to evade the model.

Financial Risk Analytics

AI can accelerate scenario analysis and risk reporting. The risk is analysts trusting AI-generated risk narratives without independently validating the underlying assumptions.

Reconciliation

AI can automate matching across systems. The risk is silent errors propagating through reconciliation processes that used to have a manual checkpoint.

Treasury Management Systems (TMS)

Many TMS platforms now embed AI features directly. The risk is that institutions adopt these capabilities without a formal review, effectively expanding their AI footprint without updating their AI inventory.

Types of AI Treasury Risk

1. Model Risk

The risk that an AI model produces inaccurate, biased, or unreliable outputs. Example: a forecasting model trained on pre-pandemic data misjudging post-disruption cash patterns. Control: independent model validation before and after deployment.

2. Data Quality Risk

The risk that poor or incomplete data undermines model outputs. Example: incomplete transaction history skewing a fraud model. Control: data quality checks built into the AI pipeline.

3. Data Poisoning / Manipulation

The risk that training or input data is deliberately manipulated to distort model behavior. Example: an attacker feeding manipulated transaction patterns to desensitize a fraud model. Control: input validation and anomaly detection on training data sources.

4. Cybersecurity Risk

The risk that AI systems become a new attack surface. Example: an exposed AI API used to exfiltrate financial data. Control: the same security testing and access controls applied to any production system.

5. Fraud Risk

The risk that AI is used offensively — deepfakes, synthetic voices, AI-generated phishing — against treasury and payment processes. Example: an AI-cloned executive voice authorizing a wire transfer. Control: out-of-band verification for high-value payment approvals.

6. Third-Party / Vendor Risk

The risk introduced by relying on external AI providers or foundation models. Example: a vendor changing its underlying model without notice. Control: contractual change-notification and model-version requirements.

7. Privacy Risk

The risk that sensitive financial or customer data is exposed to external AI systems inappropriately. Example: an employee pasting customer account data into a public AI chatbot. Control: data classification paired with technical controls on what can leave the environment.

8. Compliance Risk

The risk that AI use runs afoul of existing regulatory obligations. Example: an AI credit or risk-scoring tool producing outcomes that raise fair-lending concerns. Control: compliance review integrated into the AI approval process.

9. Operational Risk

The risk that AI failures disrupt core treasury operations. Example: an outage in an AI-dependent payment screening tool delaying settlement. Control: documented manual fallback procedures.

10. Model Drift

The risk that model performance degrades over time as real-world conditions change. Example: a fraud model becoming less effective as fraud tactics evolve. Control: ongoing performance monitoring against a defined baseline.

11. Explainability Risk

The risk that AI outputs can't be adequately explained to auditors, regulators, or the board. Example: an AI risk score with no clear rationale. Control: requiring explainability documentation for material AI decisions.

12. Human Oversight Risk

The risk of over-delegating high-impact decisions to AI without adequate review. Example: automated approval of large payments with no human checkpoint. Control: defined thresholds requiring human sign-off.

13. Concentration Risk

The risk of dependency on a small number of AI vendors or models across critical functions. Example: multiple treasury processes relying on the same foundation model provider. Control: mapping AI dependencies to identify single points of failure.

14. Dependency Risk

Related to concentration risk — the operational exposure created when core processes can't function without a specific AI system. Example: forecasting that can't run manually if the AI tool is down. Control: maintaining tested non-AI fallback processes.

15. Resilience Risk

The risk that AI-related disruption — outage, compromise, or erroneous output — isn't matched by a tested recovery plan. Example: no rollback plan when a vendor pushes a model update that changes behavior. Control: incorporating AI systems into existing business continuity testing.

16. Governance / Accountability Risk

The risk that no one is clearly accountable for a given AI system's risk and performance. Example: an AI tool adopted by a business unit with no formal risk owner. Control: an AI inventory with assigned ownership for every system.

Not every scenario above is equally documented; some (like large-scale deepfake payment fraud) are increasingly reported incidents, while others remain emerging risks institutions are right to prepare for even before widespread evidence accumulates.

Cybersecurity in Treasury: What Needs Protection?

Treasury operations depend on a specific set of high-value assets that deserve focused protection:

• Bank connectivity and payment rails
• Payment instructions and approval workflows
• Treasury management system (TMS) infrastructure
• ERP integrations feeding financial data
• Cash forecasts and liquidity data
• FX positions and exposure data
• Credentials and access tokens
• APIs connecting banks, vendors, and internal systems
• Bank account and counterparty financial information
• Financial reporting and disclosures

AI expands this attack surface in two ways: it creates new entry points (APIs, model endpoints, AI-enabled features inside a TMS) and it can accelerate attacks against the assets that were already there. Protecting treasury today means extending existing cybersecurity controls — access management, monitoring, encryption, and testing — to every AI-enabled component in the chain, not treating AI features as outside the normal security perimeter.

How AI Can Improve Cybersecurity for Banks

AI isn't only a source of new risk — it's also a meaningful defensive tool. Financial institutions increasingly use AI for:

• Anomaly and behavioral-analytics-based threat detection
• Faster fraud and phishing detection
• Security operations center (SOC) alert triage
• Automated vulnerability analysis
• Transaction monitoring at scale
• Identity and access monitoring
• Threat intelligence correlation

But AI-powered cybersecurity carries its own risks: false positives that overwhelm analysts, false negatives that miss novel attacks, model drift as attacker techniques evolve, and the same third-party dependency and explainability concerns that apply to any other AI system. The practical principle is straightforward: AI should strengthen cybersecurity capability while remaining governed, monitored, and subject to human oversight — not deployed as an unsupervised replacement for security judgment.

Many institutions discover, once they build this inventory, that AI is already embedded in vendor tools they didn't formally evaluate as "AI systems" — a common and important early finding.

AI Maturity Assessment for Treasury and Financial Services

AI governance maturity tends to progress through recognizable stages, and understanding where an institution sits helps prioritize which controls to implement first.

Initial — Limited, often informal AI adoption. Governance is fragmented or nonexistent, and there's typically no complete inventory.

Minimal — Early controls exist. AI use cases are becoming defined, and some ownership and approval processes are in place.

Evolving — Broader AI adoption paired with strengthening governance: testing, monitoring, and accountability structures are maturing across more of the organization.

Embedded — AI is integrated into core business processes with mature, continuously monitored risk controls and clear governance accountability.

This progression maps naturally onto the FS AI RMF's staged control structure — institutions earlier in the maturity curve are expected to prioritize foundational controls, while more mature institutions extend coverage further. No stage is mandatory for every institution; the right target depends on how central AI is to the organization's operations and risk appetite.

AI Model Risk Management in Financial Services

Model risk management isn't new to financial services — but AI changes some of its dynamics. Core practices still apply: validation, performance testing, data quality review, monitoring for drift, version control, change management, human review, and documentation.

What's different with modern AI models, particularly generative and third-party foundation models, is the combination of dynamic behavior, less transparent training processes, and vendor-controlled model updates that can change behavior without the institution's direct involvement. This doesn't make traditional model risk practices obsolete — it makes change management and vendor communication about model versions considerably more important than they were for static, internally built models.

Third-Party AI Risk in Treasury

Most institutions don't build their own foundation models — they rely on vendors. That makes vendor due diligence one of the highest-leverage controls available.

AI Data Privacy Risks in Financial Services

AI systems in treasury and finance frequently touch customer records, payment data, account information, employee data, and confidential business information — all of which carry privacy obligations independent of how "smart" the system processing them is.

Core privacy controls that should be part of any AI deployment include data minimization, role-based access controls, data anonymization or pseudonymization where feasible, defined retention limits, clear data residency terms, scrutiny of how vendors process shared data, and explicit restrictions on whether institutional data can be used to train external models. These controls work best when they're built into the AI lifecycle from the start — added at procurement and design time, not retrofitted after a system is already in production.

Shadow AI in Financial Institutions

Shadow AI refers to employees using AI tools that haven't been formally approved, inventoried, or assessed by the organization. It's one of the fastest-growing sources of AI treasury risk precisely because it happens outside existing governance processes.

The core problem: sensitive financial data — cash positions, forecasts, customer information, deal terms — can end up inside public AI tools with no visibility into retention practices, no vendor risk assessment, and no way to enforce deletion. Because these tools aren't inventoried, the organization often doesn't even know the exposure exists.

How Financial Institutions Can Reduce Shadow AI Risk

• Provide approved, sanctioned AI tools so employees have a legitimate alternative
• Set clear acceptable-use policies specific to AI tools
• Train employees on what data classifications are appropriate to share with AI systems
• Apply technical controls that can detect or restrict sensitive-data flows to unapproved tools
• Extend vendor governance to cover AI tools employees are already requesting
• Monitor for new, unapproved AI tool usage as part of ongoing security operations

AI Operational Resilience in Treasury

If an AI provider goes down, a model becomes unreliable, an API fails, or a vendor changes a model without warning, treasury operations need a plan that doesn't depend on the AI system working correctly. Resilience planning should address manual fallback procedures, alternative providers where feasible, rollback capability, and recovery testing that's actually exercised — not just documented. Because AI increasingly touches payment and liquidity processes directly, resilience planning for these systems belongs inside the same business continuity program as any other critical financial infrastructure, not treated as a separate, lower-priority track.

What Evidence Should Financial Institutions Keep for AI Risk?

Auditability turns AI governance from a policy statement into something that can actually be verified. Useful evidence typically includes the AI inventory itself, completed risk assessments, model documentation and validation results, data lineage records, vendor assessments, security and red-team testing results, model version and change history, monitoring records, incident logs, and documented human-oversight and approval decisions.

This evidence matters to several audiences at once — internal audit, risk committees, compliance teams, examiners, and the institution's own incident-response process when something goes wrong. Not every document here is legally required for every institution; the right evidence set depends on the institution's regulatory context and the criticality of the specific AI use case.

AI Governance and Human Oversight

Effective AI governance assigns clear accountability: a named owner for each AI system, defined approval processes before deployment, escalation paths when something looks wrong, explicit decision authority for AI-influenced outcomes, risk thresholds that trigger human review, and documentation that ties all of the above together. High-impact financial decisions — large payments, significant liquidity actions, material risk reporting — should not be delegated to AI without a defined human checkpoint, regardless of how well the underlying model has historically performed.

AI Incident Response for Financial Institutions

When model behavior changes unexpectedly, sensitive data leaks, a vendor is compromised, a model is manipulated, or an AI agent takes an unauthorized action, institutions need a response process that's been defined and tested in advance:

Detect → Validate → Contain → Assess impact → Escalate → Preserve evidence → Remediate → Recover → Review

This mirrors traditional cybersecurity incident response with one addition worth calling out explicitly: validating whether an anomaly is a genuine incident or expected model behavior often requires domain expertise the standard security team may not have, which makes early involvement from AI system owners and model risk teams important.

Likelihood ratings here are illustrative and should be recalibrated against each institution's own use cases, controls, and threat environment.

How to Build an AI Treasury Risk Management Program

Step 1 — Inventory AI use. Identify every AI system, feature, and vendor dependency across treasury and finance.

Step 2 — Classify business criticality. Determine which use cases affect material financial decisions versus lower-stakes support functions.

Step 3 — Map data and dependencies. Understand what data each system touches and what it depends on to function.

Step 4 — Assess model and vendor risk. Apply the assessment checklist and vendor due-diligence questions above to each use case.

Step 5 — Establish controls. Prioritize controls for the highest-risk use cases first, using a framework like the FS AI RMF's staged control matrix as a reference point.

Step 6 — Test and validate. Confirm controls actually work as intended, not just that they're documented.

Step 7 — Monitor continuously. Track model performance, drift, and anomalies on an ongoing basis, not just at deployment.

Step 8 — Prepare incident response. Extend existing incident response plans to explicitly cover AI-specific scenarios.

Step 9 — Maintain evidence. Keep the documentation trail current as systems, vendors, and controls change.

Step 10 — Review and improve. Revisit the inventory, risk assessments, and controls on a defined cadence as AI use expands.

When Private or Sovereign AI Can Reduce Financial Data Exposure

Private or sovereign AI architectures — models run within an institution's own infrastructure or a controlled environment rather than a shared public service — can reduce certain categories of exposure: less data leaving the organization's control, reduced dependency on a third party's infrastructure, more control over data residency, and fewer uncontrolled data flows to external systems.

They do not, however, automatically eliminate model risk, software vulnerabilities, data poisoning risk, malicious components introduced through the supply chain, insider threats, weak governance, or the risks introduced by AI agents acting with excessive autonomy. A private deployment with poor governance can still produce all the same risks discussed throughout this article — it simply changes where the exposure sits, not whether the underlying risk work still needs to happen.

How Questa AI Can Help Protect Financial AI Workflows

Everything above points to the same conclusion: financial institutions using AI need data-protection and privacy controls built into their AI workflows, not bolted on afterward. That's the specific problem Questa AI is built to help with — reducing unnecessary exposure of sensitive financial data to external AI services through anonymization, controlled AI data flows, and privacy-first workflow design.

Questa AI is one input into a broader AI risk-management program, not a replacement for it. It doesn't perform model validation, replace legal or compliance review, substitute for a cybersecurity program, conduct vendor due diligence, or serve as a regulatory filing. What it can do is help operationalize specific privacy and data-protection controls — the kind referenced throughout the data privacy, Shadow AI, and third-party risk sections above — as part of the broader program an institution builds around frameworks like the FS AI RMF.

Frequently Asked Questions