AI Agents in Finance: Use Cases, Architecture and Limits

A delayed payment, settlement mismatch, or cash shortfall can send finance teams searching across several systems. AI agents can gather those records and help decide what to investigate next. Their usefulness depends on whether they can follow the evidence reliably and recognise when a person must take over.

In this article, SDK.finance explains the use cases, features, and limits of AI agents across payment operations, treasury, reconciliation, reporting, and servicing. It examines how the architecture supports each workflow and where transaction and accounting software provides the underlying records.

What are AI agents in finance?

An AI agent is software that uses AI to choose and carry out steps towards a goal. It can retrieve information, use tools, and check results, for example, when investigating a payment issue within permissions set by the organisation.

Deloitte’s Finance Trends 2026 survey covered 1,326 finance leaders at companies with revenue above US$1 billion. Among respondents already actively using AI, 14% reported fully integrating AI agents into finance.

What makes an agent different is how it chooses the next step: it can adjust its approach as new information arrives. Anthropic’s explanation of workflows and agents describes this distinction and recommends the simplest approach that meets the task.

AI agents vs rules-based automation and copilots

The same payment exception can be handled in three ways:

• Rules-based automation flags a payment that has remained pending beyond a set threshold and follows a predefined route. It suits stable conditions and responses.
• A copilot helps an operator interpret records and draft a response. The operator directs the investigation and decides what to do next.
• An agent selects approved tools to retrieve the provider status, compare records, and create an investigation case. It still needs separate permission to retry or refund a payment.

These approaches can work together, so assess a product’s behaviour and permissions rather than relying on its label. Stable processes may need only conventional automation; exceptions that require investigation offer a different use case.

Finance workflows where AI agents can help

The following workflows show where that flexibility may help. They are possible designs, not capabilities included in every finance product. The table summarises the data and authority each would need.

Payment operations: investigate exceptions faster

For a payment exception, an agent can bring together transaction identifiers, amounts, currencies, timestamps, provider responses, and the current payment state. A case summary then gives the operator the conflicting statuses and a recommended next investigation step.

The agent may collect evidence and create a case, while retries, refunds, and instruction changes need separate approvals. A network timeout does not prove failure. The payment service must control retries; Stripe’s idempotency documentation explains how supported keys prevent duplicate operations, subject to endpoint-specific behaviour and limits.

Measure investigation time alongside incorrect retries and reopened cases. For payment authority, see SDK.finance’s guide to agentic payments.

Treasury: build a clearer cash position

Treasury teams need a cash position by account and currency before deciding how to fund upcoming payments. An agent can assemble it from timestamped bank balances, expected receipts, payment schedules, reserves, currency exposures, and minimum balance policies, flagging missing feeds and potential shortfalls. Internal balances are not automatically available bank funds.

Start with read-only analysis and alerts. Transfers, payment timing changes, and foreign exchange must follow the organisation’s approval process; a forecast cannot authorise funds movement.

Preparation time and data completeness show whether this reduces manual work. Compare forecasts with actual flows, checking whether any improvement reflects changes in the inputs.

Reconciliation: explain unmatched items

Reconciliation requires explaining why records differ. An agent can investigate exceptions using transaction and ledger records, bank or provider statements, references, fees, currencies, and dates, then propose matches with supporting evidence. Exact matching can remain rule-based, with unresolved differences kept visible for review.

Partial settlements, currency conversion, duplicate references, and cut-off times can complicate matches. The agent can suggest an explanation, but adjustments and write-offs require review.

Exception age and the false-match rate show whether investigations are becoming faster without sacrificing accuracy.

Worked example: investigate a settlement difference

Consider an unmatched settlement: the internal record shows £1,000, while the provider statement shows £990. The £10 difference could be a fee. The agent’s task is to test that explanation before proposing a match.

• Read the evidence: Check both records’ references, currency, dates, and related adjustments. Keep the exception open if required evidence is missing.
• Test the hypothesis: Verify the arithmetic with a calculation tool, then check whether the fee schedule and provider evidence support the £10 charge.
• Prepare the decision: Propose a match with evidence and remaining uncertainties. An authorised reviewer confirms the explanation and any necessary adjustment.
• Record the outcome: Verify approved changes and retain evidence and approval references. Close only after confirming resolution; otherwise hand the open exception to its owner.

Reporting: prepare explanations people can verify

The same ability to connect figures to source records can help with reporting. An agent could draft commentary explaining a change in fee income through the underlying transactions. This requires metric definitions, accounting periods, entity and currency mappings, approved ledger data, and the correct budget or forecast version.

Use tested services for calculations and make unverified causes explicit. An authorised reviewer remains responsible for publication and accounting judgements. FP&A requires separate models and approvals.

Preparation time matters only in context: frequent corrections after review can erase the time saved on drafting.

Servicing: answer financial questions with the right context

A payout or fee query often needs context from several records. With access restricted to the relevant person and case, an agent can consult authorised customer or merchant records, transaction statuses, case history, provider evidence, and policies. It can draft an answer or route the case to the appropriate team when evidence is incomplete.

Begin with narrow queries and draft responses. Refunds, account changes, disputes, and fund releases need separate controls, and an internal “completed” status may not prove that funds were received.

Track resolution time alongside reopened cases and incorrect answers. For banking workflows, see SDK.finance’s guide to agentic banking.

How much autonomy should a finance agent have?

Across these workflows, gathering information and changing financial records carry different consequences. Assign autonomy to individual actions: an agent might investigate an exception automatically, then stop for approval before an adjustment reaches the ledger.

A workflow can combine three operating modes. These are design choices, not an official industry classification.

Recommend

The agent proposes a next step; a person decides and acts. Start here for unfamiliar exceptions, accounting judgement, and incomplete data.

Act after approval

The agent prepares an operation, an authorised person approves it, and the application executes it. Reviewers need the exact action and supporting evidence.

Act within agreed limits

The agent performs a narrowly defined task under prior authority, such as creating tickets or issuing permitted status updates. Independent controls check each action.

For money movement, apply limits across repeated and concurrent requests, not just individual transactions. Escalate missing evidence, new recipients, and conflicting records according to policy.

How finance AI agents work: capabilities and architecture

Putting those boundaries into practice requires more than a model. Five components connect its decisions to controlled execution:

• Model: Interprets the task and proposes the next step.
• Orchestrator: Maintains task state, calls tools, and handles retries or escalation.
• Tools and data interfaces: Retrieve permitted records and submit defined operations to transaction systems and ledgers.
• Policy and approval layer: Checks access and authorises actions independently of the model.
• Execution records: Capture tool results, approvals, and final business outcomes.

The diagram traces the path from evidence to a verified outcome. Permission checks cover both reads and writes, while transaction systems and ledgers retain responsibility for financial state and execution.

Separate product knowledge from operational data

Keep product documentation, operating procedures, and live records distinct: they describe system capabilities, team policy, and actual account activity respectively.

Retrieval-augmented generation (RAG) supplies source material to the model but does not guarantee correctness or freshness. Operational queries need timestamps, source identifiers, and access checks.

Give the agent narrow tools

Give each tool a narrow purpose, such as retrieving a transaction or creating a case. Validate inputs before execution and return explicit statuses and errors.

Keep calculations in tested services and credentials outside the model. Limit the financial data sent to the model; define masking, retention, and access rules for prompts and outputs.

Enforce policy outside the model

Enforce account, recipient, amount, currency, and approval rules in the application. Prompt instructions are not authorisation.

Show reviewers the exact operation and evidence. Recheck approval if material details change, and preserve separation of duties.

Verify the outcome and retain a trace

Verify the business outcome after each call. An accepted API request may still require a later status update or external confirmation.

Log source references, tool calls, approvals, and outcomes so operators can reconstruct actions. Restrict access to sensitive logs.

Limits and failure modes to design for

These controls need testing against failure as well as success. A convincing explanation can still rest on incomplete records, manipulated instructions, or a misunderstanding of the transaction.

Incorrect or incomplete evidence

A missing settlement file, stale balance, or changed account mapping can make a correct-looking analysis unusable. Define freshness and completeness requirements, and make missing inputs visible. The workflow should stop or qualify its output when those requirements are not met.

A balanced journal entry also does not prove correct accounting treatment. Debits and credits can balance while the wrong accounts, period, or business event are used. Ledger validation and accounting review serve different purposes.

Instructions hidden in source material

An invoice, support message, or retrieved document can contain text that tries to redirect the agent. Treat that text as data rather than authority to change the task or its permissions.

OWASP describes excessive agency as a risk arising when an AI system has enough functionality, permissions, or autonomy to cause harm after an incorrect or manipulated output. Narrow tools, limited access, and independent approval controls help contain the consequences.

Duplicate actions and partial completion

A workflow can fail between submitting an instruction and recording the result. Define how it checks the existing state before retrying, how it handles duplicate events, and when an operator must intervene.

Recovery depends on the operation. A ticket may be editable; a completed payment may need a separately authorised refund or another corrective process. Do not assume that every financial action has a simple undo function.

Costs that exceed the benefit

An investigation may take fewer staff minutes yet cost more once model calls, integrations, review, and rework are included. Compare the full cost with simpler automation before choosing an agent.

How to choose your first workflow

A manageable pilot makes those trade-offs measurable. Choose a task with accessible evidence, a clear completion condition, and an accountable owner, such as a reconciliation investigation or reporting preparation.

• Define the task: specify the input, expected output, permitted actions, and conditions that require escalation.
• Establish a baseline: measure current handling time, errors, rework, and cost before introducing the agent.
• Test representative cases: include missing data, conflicting records, ambiguous statuses, and attempts to redirect the agent.
• Start with observation or recommendations: compare outputs with reviewed outcomes before granting write access.
• Expand authority only when justified: check performance, monitor exceptions, and retain a way to suspend execution.

Set quality and efficiency thresholds before the pilot so the decision to continue rests on agreed criteria.

How to measure value before expanding autonomy

Compare the pilot with the current process on similar cases over the same period. Count only outputs that meet the agreed completion and quality criteria:

• Pair speed with accuracy: use the workflow-specific measures above and include review time, so faster drafts do not conceal additional checking or correction.
• Calculate cost per correctly completed case: divide the full workflow cost by the cases that pass review. Include model usage, integrations, data preparation, monitoring, review, rework, and a defined share of implementation costs.
• Assess ROI over a stated period: (measured benefits minus total costs) / total costs. Do not count the same benefit twice as both released staff time and reduced staffing expense.

Illustrative calculation:

• Current process: 20 minutes per case.
• Pilot: five minutes to gather evidence plus seven minutes for human review, saving eight minutes per case.
• Across 1,000 comparable cases: about 133 staff hours released before setup, oversight, and rework.

Released time creates capacity for other work; it becomes a cash saving only when an actual expense falls. Any increase in authority must preserve the agreed quality level and cover its additional control and operating costs.

Where SDK.finance fits in a finance AI workflow

SDK.finance builds financial software for FinTech companies, payment providers, and financial institutions. Our Transaction Platform manages accounts, balances, and transactions, while our General Ledger records the accounting impact of business events. For teams building AI agents for finance operations, these products provide two kinds of evidence an agent can use to investigate a case.

Take the £10 settlement difference from earlier in the article:

• The SDK.finance Transaction Platform provides the internal payment record, including its status, amount, currency, and provider reference where available.
• The SDK.finance General Ledger shows how the payment and any recorded fee were posted under the organisation’s accounting rules. The provider’s statement supplies the external evidence of what was settled and which fees the provider reported.

In a read-only pilot, an agent with access to those records could bring them together in a single case summary, cite the evidence for the £10 difference, and flag anything it could not verify. The reviewer can then decide whether the evidence supports a match or the case needs further investigation.

Build reliable workflows before expanding autonomy

An agent earns a place in finance operations when its output helps a team resolve a case, understand a difference, or prepare a report with less rework. Start with a bounded workflow, measure the reviewed result, and let that evidence determine how much authority to grant.

Reliable records, suitable integrations, and independently enforced controls are what make that result repeatable. To assess the underlying foundation, discuss your workflow requirements with SDK.finance, including the records needed, permitted actions, and approval points.