Financial services are entering another cycle of automation in 2026. Over the past two years, companies have used large language models for data search, internal chat tools, and specific analytical tasks. Attention is now moving to AI agents that can complete a sequence of actions: choose a datadecision, and pass the output to the next stage of a process
Lloyds Banking Group has described a similar shift, calling 2026 the year when financial services start moving from familiar AI tools towards agent-based systems.
My interest in B2B fintech is practical. I want to understand which tasks can already be handed to agents without losing control, where the risk of an expensive error becomes unacceptable, and what architecture is needed to scale these systems within a product.
How AI Agents Extend Existing Automation
Fintech automation has traditionally used fixed rules, scripts, and robotic workflows for predefined sequences of actions.
Machine learning models cover specific tasks such as scoring, classification, ranking, and forecasting.
AI agents operate at a different level. They can handle the full task cycle: receive a request, choose the tools they need, query data, formulate intermediate queries, check the results, prepare a report, and explain their conclusions.
Teams prepare reports, investigate unusual movements, answer recurring business questions, test hypotheses, and check which data is available. A large share of the time goes into finding information and preparing the business context before the analysis starts. This preparatory work is a sensible place to start with AI agents.
What We Are Already Testing
My team is testing several use cases across analytics and operations. Each follows a repeatable sequence of actions and has reasonably clear criteria for assessing the result.
One use case is analytics on demand. A business user asks a question in a chat, and the agent uses the available data sources to prepare a structured report. The first version worked with internal admin interfaces and produced fairly simple reports for business users. We are now testing more complex analytical tasks in an isolated database environment. The agent has no direct access to production systems.
Another use case is operational monitoring for technical teams. The agent analyses event logs in Elasticsearch, identifies signals that may matter, groups similar incidents, and prepares a short summary for the people responsible for the service.
A third use case supports the analytics team. The agent helps with backlog grooming, carries out an initial check of a hypothesis, drafts queries, finds relevant data, and works out whether a business idea can be tested with the sources we already have. Analysts still review the work. The agent handles some of the preparation and reduces the time needed to reach a first workable answer.
A separate practical use case covers offer ranking across groups of sites.
Ranking is usually managed by people, with conventional algorithms and machine learning models supporting some parts of the process. Our live experiment focused on the AI agent against the usual manual process.
For the first live test, we selected several representative partner websites with substantial traffic volumes and performance close to the portfolio average. Incoming traffic was split randomly and roughly equally between two variants. One group saw the offer order prepared in the usual way by a manager. The other saw the order produced by the AI agent.
We compared the revenue generated by each variant on comparable traffic. During the first month, the agent-controlled ranking generated about 10% more revenue than the manual version. This is a relative uplift against manual management. We are treating it as an early result while the experiment continues, as one month is too short to establish a stable long-term effect.
The role of the agent was developed in two stages.
In the first stage, the agent followed the same basic logic as a manager. Its skills gave it access to our admin panel, which also serves as the team’s BI interface. It read EPC, CTR, and approval rate for each offer, then changed the order using the same metrics and rules used in manual management. The checks ran on a schedule, so the agent could continue reviewing the figures outside normal working hours.
For the next stage, we built a separate Greenplum environment containing only the data needed for the experiment. It is separate from the main data warehouse and holds a partial copy of the required tables with regular updates. Database access goes through an intermediate layer, and the agent can run only the approved queries exposed through its skills.
Those database skills let the agent use client-flow data when building a ranking. The available data includes internal scores produced by conventional PD models. The agent does not calculate the scores. It reads the existing values and combines them with recent offer metrics and historical performance by score bucket.
This introduced personalized ranking. A manager working from the admin panel normally sees aggregate offer metrics and does not have customer-level PD scores or the same DWH detail. The agent can use the score bucket of an individual customer and the historical performance of offers in that segment when deciding the order.
Re-ranking normally runs once a day. The system uses current performance and a short retrospective window to calibrate the order, then sends the resulting configuration through an API.
Existing eligibility rules are applied before the ranking is used. The agent cannot override them or change product terms. If a customer has already received a loan through a particular offer, that offer is removed for the customer permanently because another interaction would not generate further commercial value. Following a rejection, the restriction is temporary, and the customer can become eligible again after the defined period.
The people responsible for the sites can step in when a faster response is needed. Through a separate chat interface, they can ask the agent to move an offer up or down for a particular group of sites, remove it, or put it into a specific position.
OpenWebUI provides the chat interface. MLflow tracks activity across the agent workflow.
The current version uses the operating logic of a manager together with customer-level scores and selected historical data from the DWH. This allows the ranking to reflect the characteristics of the incoming customer flow, instead of applying one offer order to every user.
Where We Draw the Line on Autonomy
In my experience, agent-based systems are most effective when they do not make critical financial decisions themselves, but instead automate the repetitive processes around those decisions. I would consider an agent a sensible fit when the databe reproduced, every step is logged, and a person can review the output
The simplest test is whether a single mistake can cause a direct financial loss.
For now, it makes sense to delegate tasks such as report preparation, initial analysis, and interpretation of metrics to agents. Changing production rules or taking actions that directly affect customers requires much tighter control. Once an agent can touch payments, personal data, or customer-facing actions, access controls, reproducibility, and the surrounding architecture become much more important.
Why Data Is the Main Constraint
One of the main findings from our PoCs concerns data. Many of the limitations we have encountered are related not to model quality, but to data quality and the surrounding business context. Database access on its own provides too little context. The agent has to know what the tables mean, how the sources relate to one another, how each metric should be used, and which datasets the business actually trusts.
A technically correct query can produce the wrong business conclusion when this context is missing. The agent may choose the wrong table, misunderstand a status, compare metrics built on different definitions, or use aopped trusting it
The data layer, therefore, needs a catalogue describing tables and metrics, data lineage, agreed rules for business indicators, clear ownership of key entities, and a shared semantic layer. Poor definitions and unclear context are then repeated at scale. In fintech, even a small difference in how teams define a conversion, successful application, approval, rejection, or returning customer can affect a whole chain of product and operational decisions.
Problems That Appear Even at the MVP Stage
Reproducibility becomes a problem almost immediately. If an agent produces a report or recommendation, the team needs to know which data it used, which filters it applied, which tools it called, and why it reached that conclusion. Logging actions, retaining intermediate artefacts, and replaying the process step by step are needed from the MVP stage.
Access rights create another set of constraints. An agent should have only the access it needs for the task in front of it. In fintech, production systems, personal data, credentials, and actions that can affect customers or financial processes all need particular care.
The interface creates a separate challenge. Many agent tools work well in technical environments. Adapting them for business teams is harder. A business interface needs action confirmation, charts, files, and intermediate results alongside the chat.
Cost also needs monitoring. An agent can take an unnecessarily long route, repeat requests, or produce a confident answer when the available data is not good enough.
A production setup, therefore, needs sensible limits, resource monitoring, and human review where the risk justifies it.
What Changes after the Demo
The work changes once a functioning demo becomes a system used by real teams. The model becomes one component within a wider system. The team then has to manage data understanding, action constraints, reproducibility, and the cost of possible errors.
Our early results point to agents operating within clear limits as the most useful option for fintech. Those limits include trusted data, restricted access, traceable actions, and a person who can step in when the business context demands it.
Figure 1. High-level architecture of the chat subsystem
