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.
• Treasury's 2024 report and its 2026 framework are separate publications. The 2024 report describes risks, use cases and next steps; the 2026 framework gives institutions a structure for managing them.
• The FS AI RMF, released by Treasury in February 2026, is voluntary, sector-specific guidance that adapts the NIST AI Risk Management Framework for financial institutions. It is not a regulation.
• 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.
• 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 Treasury Has Published on AI Risk in Financial Services

Treasury has addressed AI risk in financial services in two separate publications, and they do different jobs.

March 27, 2024: the AI cybersecurity report. Treasury released Managing Artificial Intelligence-Specific Cybersecurity Risks in the Financial Services Sector, written at the direction of Executive Order 14110 and led by its Office of Cybersecurity and Critical Infrastructure Protection. The report drew on in-depth interviews with 42 companies, ranging from global systemically important institutions to local banks and credit unions, along with technology providers, trade associations and regulators. It described how firms use AI for cybersecurity and fraud prevention and set out ten next steps. These included a widening capability gap between large and small institutions, a fraud data divide that leaves smaller firms with less to train on, concern about regulatory fragmentation, a call to tailor the NIST AI Risk Management Framework to financial services, better mapping of data supply chains, explainability for black-box models, skills gaps, a common AI lexicon, digital identity, and international coordination. Treasury stated that the report imposes no requirements and neither endorses nor discourages the use of AI in the sector.

February 18 to 19, 2026: the AIEOG initiative and framework. On February 18, 2026, Treasury announced the conclusion of a public-private initiative carried out through 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). Treasury said it would release six resources over the course of February, designed to help institutions, particularly small and mid-sized ones, use AI to strengthen cyber defenses and deploy it more securely. It emphasized practical implementation rather than prescriptive requirements. The first two resources followed on February 19: a shared AI Lexicon and the Financial Services AI Risk Management Framework.

The 2024 report did not introduce the 2026 framework. It did, however, call for a common AI lexicon and a financial-sector version of the NIST framework, and the 2026 resources address both. Treasury's announcements describe risks, use cases, recommendations and tools. They do not catalogue specific incidents, and where this article discusses threats such as deepfake-enabled payment fraud, it treats them as risks institutions should plan for, not as events Treasury has documented.

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?), 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 Is the Financial Services AI Risk Management Framework?

The Financial Services AI Risk Management Framework (FS AI RMF) is voluntary guidance that adapts the NIST AI Risk Management Framework to the operational, regulatory and consumer protection needs of financial services. Treasury released it on February 19, 2026, alongside the AI Lexicon, and describes it as scalable and flexible enough for institutions of different size and complexity. It was developed through the AIEOG, with the Cyber Risk Institute closely involved; the institute's CEO is quoted in Treasury's announcement, which also links to the AIEOG page where the materials are available.

The framework follows the NIST structure of Govern, Map, Measure and Manage. According to industry summaries of the published materials, it has four parts: an adoption stage questionnaire, a risk and control matrix, a guidebook and a control objective reference guide. Treasury says it helps institutions evaluate AI use cases, manage risk across the AI lifecycle, and build accountability, transparency and resilience into deployment decisions.

The framework is not a law or a regulation, and Treasury's materials do not require any institution to adopt it or to implement every control. Following it also does not guarantee security or compliance with any particular rule. Its value is as a common structure: a way to describe what AI an institution uses, who owns it, which controls apply, and what evidence shows those controls are working.

What Are the 230 AI Risk Control Objectives?

The framework's risk and control matrix contains 230 control objectives. That figure comes from the Cyber Risk Institute's framework materials, not from Treasury's press release. The objectives cover areas such as governance, data, model development and validation, monitoring, third-party risk and consumer protection. They are scoped by AI adoption stage (Initial, Minimal, Evolving and Embedded): an institution completes the adoption stage questionnaire and applies the objectives that match its stage, instead of working through all 230 at once.

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.

How to Use the FS AI RMF in a Treasury AI Risk Assessment

A treasury team does not need to start with the full matrix. A workable sequence looks like this.

Start by listing every AI system and AI-enabled vendor feature that touches treasury, including features switched on inside a treasury management system that nobody formally reviewed. The adoption stage questionnaire is only as accurate as that list. An understated inventory produces an understated stage, and with it too few controls.

Next, use the questionnaire result to find the control objectives that apply at your stage, and give each one a named owner. For an AI-assisted cash forecast, model validation might sit with model risk, the data feeds with treasury operations, and vendor change notices with procurement or third-party risk.

Then record the evidence for each control: the validation report, the access review, the vendor assessment, the test of the manual fallback. Auditors and examiners ask for evidence, not intentions, and a control with no evidence is hard to defend.

Finally, put monitoring on a schedule and revisit the assessment when a vendor changes a model, when a new use case is added, or when an incident shows a control did not work as expected. The framework is built around the full lifecycle, so the assessment is never finished.

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.

What These Controls Look Like in Practice

An AI-assisted cash forecast. The forecast draws on bank balances, receivables and counterparty data, so the first question is what data leaves the institution and whether the vendor can use it to train its own models. After that, back-test the forecast against actual cash positions and agree a tolerance that triggers review, so a confident-looking number built on stale data does not drive a funding decision. Keep a manual forecasting method that has actually been run recently, not just documented, so treasury can operate if the tool is unavailable during a liquidity event.

AI-assisted payment anomaly detection. A model that flags unusual payments is useful only if its misses and false alarms are measured, so validate it before relying on it and monitor for drift as payment patterns change. Limit who can change thresholds, and log every change. Most importantly, keep a human approval step and independent verification for high-value payments no matter what the model scores. The model should help decide what gets reviewed, not release the payment.

An AI-enabled treasury management system. Many platforms add AI features through routine updates, which quietly expands the institution's AI footprint. Ask the vendor to disclose AI features and notify you of model changes, add those features to the AI inventory, and review the system's API credentials and service accounts for least-privilege access. Write down who accepted the risk of each feature, and make sure the incident plan covers switching the AI feature off while the core system keeps running.

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: manipulated transaction patterns fed in 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, through deepfakes, synthetic voices or AI-generated phishing, against treasury and payment processes. Example: an AI-cloned executive voice used to request 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, this is 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, whether an 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.

These threats are not equally well documented. Treasury's announcements describe AI-enabled fraud and cybersecurity as risks the sector needs to manage, but they do not catalogue specific incidents, and nothing in the table should be read as a confirmed event at a particular institution. Treat it as a planning aid: the controls apply whether or not a given attack has been observed.

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, including access management, monitoring, encryption, and testing, to every AI-enabled component in the chain, and not treating AI features as outside the normal security perimeter. Credentials, API keys and access tokens are among the assets on that list, and teams can keep them out of AI prompts with controls like those described in Questa's guide to AI data security for cyber and critical data.

How AI Can Improve Cybersecurity for Banks

AI isn't only a source of new risk. It is 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." That is 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 and 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, such as cash positions, forecasts, customer information, and 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, such as large payments, significant liquidity actions, and material risk reporting, should not be delegated to AI without a defined human checkpoint, regardless of how well the underlying model has historically performed. The number of systems that need an owner grows quickly as AI agents multiply across workflows, a problem covered in more detail in AI agent sprawl.

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, meaning 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

Conclusion

Treasury has published two distinct sets of material on AI in financial services. The March 2024 report described the cybersecurity and fraud risks, use cases and open gaps that institutions face. The February 2026 initiative produced practical tools, including the voluntary FS AI RMF, to help institutions manage those risks in a structured way. Neither is a regulation, and neither promises security or compliance on its own.

For treasury teams, the practical work is the same whichever publication prompted the question. Know which AI systems and vendor features are in use. Protect the customer, payment and treasury data they touch. Keep a human and an independent check on high-value payments. Validate and monitor fraud and forecasting models for drift, and keep a tested non-AI fallback ready. Record who owns each decision and keep the evidence. Technology that limits what sensitive data reaches external AI services, such as Questa AI, can support one part of that program, but it works alongside governance, model risk management and human oversight, not in place of them.