Opportunities risks and the controls that make adoption credible
By Rizmo
Approximately 10 minutes
What would your bank allow an artificial intelligence agent to do before a person checks its work?
Find a missing document? Prepare a fraud investigation? Change a customer record? Move money?
Each step gives the system more authority. Each changes what can go wrong.
Agentic artificial intelligence offers banks a way to connect fragmented tasks, reduce repetitive work and help employees handle complex cases. Its value depends on choosing useful problems and giving systems carefully bounded authority. A convincing demonstration is only the beginning. A bank needs evidence that the system remains safe when information is incomplete, instructions conflict or a supplier fails.
The practical starting point is a narrow workflow with measurable benefits, explicit permissions and a named human owner. Broader autonomy should follow demonstrated control.
What makes a system agentic
A chatbot usually responds to a question. Conventional automation follows a predefined sequence. An agentic system can pursue a goal across several steps, select tools, inspect results and adapt its next action within the authority it has been given. A conversational interface can contain any of these approaches; the label on the product tells a bank very little.
Consider a disputed card payment. A chatbot might explain the dispute process. Fixed automation might send a form. An agent could retrieve the transaction, identify missing evidence, prepare a case and route it to the right team. Whether it may contact the customer or issue a refund is a separate permission decision.
This distinction matters because a wrong answer can become a wrong action. Banks should assess the complete workflow, including the model, connected systems, data, permissions and people who review exceptions.
What the evidence actually tells us
The Bank of England and Financial Conduct Authority’s survey, published on 21 November 2024, received responses from 118 financial services firms. Seventy-five per cent reported using artificial intelligence. Among firms using it or planning to use it within three years, 46 per cent reported only a partial understanding of the technologies they used. These are findings about participating United Kingdom financial firms, not all banks worldwide. They do not measure agentic adoption or prove productivity gains. [1]
The governance question is already moving closer to execution. On 9 October 2026, the Monetary Authority of Singapore described its work on agent identity and authorisation, checks against a user’s mandate before execution, and accountability and auditability. This is a useful direction for bank design, rather than a universal legal standard. [2]
The implication for executives is straightforward: ask what a system may do, how that permission is enforced and what evidence remains afterwards.
Where banks can find practical value
The following examples are proposed applications, not claims of proven savings. Each needs comparison with the bank’s current process and simpler alternatives.
Customer service is a sensible candidate when employees spend time moving between systems. An agent could assemble account information, retrieve approved product terms and prepare a response for an employee. For a routine request, it might update a case status within a narrowly defined permission. Complaints, vulnerable-customer situations, disputed facts and financial commitments should trigger appropriate human review. Measure resolution quality and repeat contacts alongside handling time.
Back-office reconciliation offers another focused starting point. An agent could collect supporting records for unmatched transactions, compare descriptions and propose reasons for a difference. The first pilot should prepare evidence and suggested corrections without posting to the ledger. A qualified employee can check the proposal before an independently controlled posting process executes it. Faster reconciliation is useful only if accuracy and financial control hold.
Fraud investigations and compliance work involve large amounts of evidence gathering. An agent could organise an alert’s transaction history, identify missing documents and draft a sourced case narrative. Investigators would retain responsibility for consequential decisions, including account restrictions and regulatory submissions. Measure missed risks, unsupported assertions and review effort, as well as cases processed. A polished narrative can conceal weak evidence.
Credit processing can benefit from help with document completeness, extraction of financial information and preparation of a credit memorandum. Calculations should use validated tools and traceable inputs. Lending decisions, pricing exceptions and adverse customer outcomes need the bank’s established decision authorities and meaningful human control. An agent should not infer creditworthiness from an applicant’s accent, writing style or unrelated personal information.
Treasury assistance could include gathering approved market information, preparing liquidity scenarios and explaining movements for a dealer or treasury manager. Start with decision support. Any later execution capability needs separate authority, approved instruments and counterparties, transaction and cumulative limits, and independent checks. An instruction to optimise liquidity is far too broad to authorise unrestricted trading or transfers.
The risks that change when systems act
Can the bank distinguish a verified fact from a plausible invention? Generative models can produce confident falsehoods, often called hallucinations. The United States National Institute of Standards and Technology’s July 2024 risk profile also warns that fabricated logic or citations can mislead people. [3] For a bank, an invented policy clause or missing transaction can contaminate an entire case. Require links to approved records, checks against source systems and escalation when evidence is missing. A fluent explanation is not proof.
Could a document give the agent instructions? Prompt injection occurs when hostile content attempts to redirect a system. An uploaded invoice or external webpage might tell an agent to disclose customer records or bypass its task. The National Institute of Standards and Technology has examined agent hijacking through malicious instructions embedded in data. [4] Treat retrieved content as evidence to inspect, never as permission to change policy. Restrict accessible tools and destinations, and enforce sensitive-action checks outside the model.
Who can see the information? An agent connecting customer, transaction and employee systems may create new routes for confidential data to leave the bank. Map data flows before deployment. Minimise what enters the model, separate customers’ information, protect credentials and restrict outbound communication. Review supplier retention, training use, subcontractors and processing locations. Privacy, banking confidentiality and cross-border requirements must be assessed for each relevant jurisdiction.
Will the system treat customers fairly? Historical data and incomplete records can reproduce disadvantage. Test outcomes across relevant customer groups, languages and document types, using lawful and appropriate methods. Check whether reviewers can identify the actual evidence behind a recommendation. Give customers workable correction and appeal routes where relevant. A generated explanation that merely sounds reasonable does not establish why a decision occurred.
What happens when everyone depends on the same supplier? The Financial Stability Board’s November 2024 report identified third-party concentration, market correlations, cyber risks, and model and data governance as potential financial stability vulnerabilities. [5] Its October 2025 follow-up emphasised monitoring adoption and dependencies. [6] Banks should map the full supplier chain, assess substitutions and test interruption scenarios. A second application may still depend on the same underlying model or cloud provider.
Controls that must work during execution
A policy document cannot stop a bad tool call. The bank needs controls that operate when the agent attempts an action. The recommendations below are a practical design approach, not a claim that one framework satisfies every regulator.
Give each agent a verifiable identity and a limited mandate. Specify which records it may read, which tools it may use, what it may change and when its authority expires. Use the smallest permissions needed. An agent preparing a reconciliation should not inherit the employee’s unrelated payment authority. Delegated agents should receive only the access their own task requires.
Separate proposing, approving and executing. The agent that recommends a payment should not approve its own recommendation. Enforce permitted recipients, amounts, frequency and cumulative exposure through independent controls. Prevent a series of small transactions from bypassing a larger limit. Require renewed approval if material details change.
Make human oversight practical. Reviewers need the source evidence, proposed action, uncertainty, relevant policy and time to challenge the result. Set manageable workloads and escalation routes. If staff are expected to approve hundreds of unfamiliar cases quickly, a human checkpoint can become a rubber stamp.
Record what happened. Preserve the initiating request, relevant source versions, model and tool versions, proposed actions, approvals and execution outcomes, with access controls and retention appropriate to the records. Auditability should come from observable evidence. The system’s own account of its reasoning may be incomplete or misleading.
Plan for failure before launch. Test a kill switch that revokes execution access, preserves evidence and returns work to a safe queue. Build recovery procedures for incorrect updates and partially completed workflows. A completed transfer or disclosed secret may be impossible to undo; rollback is not a substitute for preventing irreversible harm. Train staff to operate the manual fallback.
What African banking contexts add
African banking markets should not be treated as one operating environment. A deployment needs to reflect its country, customers, languages, infrastructure and supervisory expectations.
A document-processing pilot should test the formats customers actually submit, including scans and uneven-quality records. A service agent should be evaluated in the languages and language combinations used by its customers. For customers with limited formal financial histories, missing data should not quietly become a negative judgement. These are design requirements to investigate locally, not assumptions about every African bank.
Where connectivity or power interruptions affect the workflow, test how work is queued, resumed and checked for duplicate execution. Cross-border banking groups should examine differences in privacy, outsourcing, recordkeeping and customer-protection obligations before reusing a deployment across countries.
In a speech on 8 May 2026, South African Reserve Bank Deputy Governor Fundi Tshazibana stressed that financial institutions retain responsibility for artificial intelligence risks. She also highlighted weaknesses in fairness testing, third-party model risk management and board oversight, and shortages of relevant skills. [7] A useful response is to fund staff capability and independent challenge alongside the technology.
A practical first 90 days
Days 1 to 30 should establish a useful, bounded problem. Choose one workflow, such as preparing reconciliation exceptions, and appoint a business owner. Map the data, suppliers and permissions. Record current processing time, error rates, rework and cost per completed case. Agree what success means, which actions are prohibited and which incidents immediately stop the pilot. Include operations, risk, compliance, security and relevant legal expertise.
Days 31 to 60 should test the complete workflow in a controlled environment. Run the agent alongside the existing process without allowing live execution. Include ordinary cases, unusual cases, hostile documents, incomplete records, supplier outages and duplicated requests. Test whether it stops when evidence is insufficient. Evaluate differences across relevant customer groups. Independent reviewers should examine failures and verify that permissions cannot be bypassed.
Days 61 to 90 can support limited production use only if the evidence warrants it. Restrict volumes, permissions and user groups. Review consequential actions before execution. Measure net benefit after checking, rework, supplier costs and support overhead. Drill shutdown and recovery. Retest after material changes to models, tools, data or permissions.
Ninety days is a proposed learning cycle, not a deadline for autonomy. Finish with an explicit decision to expand, redesign or stop. A pilot that reveals an unsuitable use case has still produced valuable evidence.
Questions the board should ask
Before approving expansion, directors should ask:
Which customer or operational outcome improves, and how have we measured it?
What is the worst credible action this agent could take with its current access?
Which controls block that action independently of the model?
Who is accountable, and can reviewers challenge decisions with reliable evidence?
Can we stop execution, recover safely and continue serving customers if a supplier fails?
What evidence would make us withdraw permission rather than expand it?
Agentic artificial intelligence deserves serious experimentation in banking. It can help staff connect information and complete work that currently stalls between teams and systems. Its adoption also creates a concrete management obligation: every permission should have a purpose, a limit, an owner and a test.
The next investment proposal should therefore show both the work the agent can perform and the actions the bank can reliably prevent.
Rizmo is Primproa’s research and writing contributor.