AI agents are arriving in financial products quickly - support, transaction analysis, recommendations, the automation of work nobody wanted to do by hand. The technology usually works. The adoption often does not, and when it does not, the interface is a more common cause than the model.
In most products a design failure costs an abandoned cart. In fintech it costs the user at the exact moment their money is involved, which makes trust a conversion factor rather than a brand quality.
So the agent has a double brief. Be useful, and be clear enough that a person will authorise it to act. The second half does not solve itself when the first half is excellent, and it is almost entirely an interface problem.
The user has to know they are talking to a machine
The first question the interface answers is identity. Is this a bot, an assistant, an adviser? What is it called, how does it speak, what does it do when it is wrong?
Humanise it too far and the person loses track of what they are dealing with, which in a financial context reads as being handled rather than helped. Strip it too far and it becomes an auto-responder nobody reads. The useful position is a consistent character that never pretends to be a person: a fixed voice, a fixed way of admitting a limit, and the same behaviour every time.
Blurred identity produces anxiety, and anxiety is expensive here in a way it is not elsewhere.
Show the reasoning, not only the conclusion
The most common failure is an agent that gives a verdict and hides the path to it. Move thirty percent of the portfolio into bonds. The user sees the recommendation and has no way to evaluate it, so they do not act on it.
In an ordinary product that might survive. With savings attached it does not: nobody executes an instruction they cannot check.
Explainability belongs in the interface, not in a whitepaper. Every conclusion carries a short answer to why, expandable for the people who want the detail. It does not need to be long - one honest sentence with a way in beats a paragraph nobody opens.
MontNoir is the version of this I have designed end to end. It sells a penetration test run by an agent, to buyers professionally trained to distrust automated findings - and rightly, because a false critical costs more than it saves. The answer was not to make the automation look more convincing. Every finding ships with its evidence and the steps to reproduce it by hand, so a stranger can disprove it without asking us for anything. That is what made the findings worth paying for.
An agent that cannot be checked is an agent that has to be believed, and belief is not a product feature.
Every state visible, especially the refusals
An agent works asynchronously: it reads, it reasons, it acts. To the person waiting, that is a stretch of uncertainty, and uncertainty about money is not neutral. A spinner is not state design, it is the absence of it.
Name what is happening while it happens. Checking transaction history. Verifying pricing data. Assembling the report. The run narrates itself, the person can see the work, and they stay in the dialogue instead of deciding it has hung.
The refusal states matter most and get designed last. When the agent cannot do something - a regulatory limit, missing data, a permission it does not have - the interface has to say so plainly and offer the next move. I cannot do this, here is why, here is what you can do instead. That outperforms a bare rejection by a wide margin, because it keeps the person inside the product rather than sending them to support.
Propose, confirm, act
Financial decisions are where a person most wants the last word. An agent that acts on its own without explicit consent makes even a technical audience uneasy.
So the model is proposal, then confirmation, then action. The agent suggests, explains, and waits. This is slower than full automation and it is the reason anyone uses the automation at all, particularly for the first few transactions.
Autonomy can be earned later. Once someone has watched the agent be right a number of times, the product can offer to let it act alone - as an explicit choice, with manual control always one step away. Autonomy granted is trusted. Autonomy assumed is not.
An empty input is a barrier, and a paragraph is a wall
Two interface habits do most of the work here, and both are about removing effort rather than adding capability.
The first: never open with an empty field. A blank prompt asks a person to be precise before they know what is available, which is the same failure as the empty search box in any marketplace. Offer concrete openings drawn from where they actually are. Someone on the pricing screen should be offered a cost calculation or a plan comparison, not a blinking cursor.
The second: answer with objects, not prose. People scan a chat, they do not read it, and by the second paragraph they are gone. A filled-in transfer form, a chart, a confirm button - one action instead of six sentences. The agent stops describing what could be done and hands over the thing itself.
The same instinct runs through Gettran, where the power users act through inline Telegram commands and never open the interface at all, which leaves the interface free to serve everyone else.
- Open with options drawn from the current screen, never a blank field
- Reply with a form, a chart or a button before replying with a paragraph
- Name the current step while the agent is working
- Say what you cannot do, why, and what to do instead
The handoff to a person carries the context
An agent handles most of the standard load. The individual cases need a human, and that is the normal shape of the thing, not a failure of it.
What decides whether the handoff costs trust is whether the person has to start again. Move the conversation to an operator with a summary attached, so nobody is asked to retype what they already explained. The experience stays continuous and the escalation reads as the product working rather than the product giving up.
Compliance copy is a design problem
Fintech runs inside rules, and an agent giving financial guidance has disclosure and protection obligations attached to it. Teams treat that as a legal task and hand it to the footer.
It is a design task. How do required disclosures sit in the flow without wrecking it? How do you state a limitation honestly without making the product look unreliable? How do you build a step where someone makes an informed decision instead of clicking through an agreement?
Solving that in the interface rather than in small print produces products that survive both the user and the regulator, which is the only durable version of shipping this category.
An AI agent in a financial product is a new kind of relationship between a company and a person, and the interface decides whether it forms at all. The model can be excellent; if the design does not make its work legible, most people will use a fraction of it and trust less than that. Everything above is one instruction repeated: make the machine easy to check.