A prospective user is four screens into opening an account. They have entered their details, agreed to the terms, and now they are being asked to upload proof of address.
They pause. Does a bank statement count if it is a PDF? Does a phone bill work? Why does a company they met eleven minutes ago need to know where they live? Support is closed. They close the tab, intending to come back, and do not.
That user cost you real acquisition spend. They were most of the way to converted. They left over a question with a one-sentence answer.
Onboarding is where the money leaks
Fintech has an unusually expensive funnel. Acquisition is competitive and paid, the product is often free at the point of signup, and the entire return depends on getting people through verification.
Verification is also the least pleasant part of the experience. It asks for things people are trained to protect, at a moment when trust has not been established, with no explanation of why.
The friction is not the requirement. It is the silence around the requirement. Two categories of question kill signups here:
Practical. Which documents count. Whether a digital statement is acceptable. How recent it needs to be. What to do if the address does not match. How long verification takes. What happens if it fails.
Reassurance. Why do you need this. What happens to my ID after. Who sees it. Is this normal.
Both are answerable in a sentence each. Neither is usually answered anywhere the user can find at the moment they stall.
In-flow beats a help centre
The critical detail is where the answer appears.
A help centre article explaining acceptable documents is worth very little, because a user mid-abandonment does not open a new tab and search. They give up in place. An assistant available in the flow, answering the question at the point of hesitation, converts a share of exactly the people who would otherwise be gone.
This is the strongest argument for a chatbot in fintech, and it is worth measuring specifically: completion rate for users who interacted with the assistant at the verification step, against those who did not.
Fees, and the trust dividend
The second cluster is pricing. Financial products are perceived as full of hidden charges, and a large amount of support volume is people trying to establish what something actually costs.
Answering plainly is a competitive advantage in a category where most players are vague. What the FX margin is. What happens on a weekend transfer. Whether there is a fee for an ATM withdrawal abroad, and what the limit is. What the account costs if it sits dormant.
A bot that answers those directly from your published schedule builds more trust than any amount of marketing copy about transparency.
The regulatory line
This is the boundary to write before anything else, and it is not negotiable.
Acceptable: factual product mechanics, fee schedules, how features work, onboarding steps, documentation requirements, timelines, what a status means, general financial education that is not tailored.
Not acceptable: anything that recommends a product, comments on whether something suits a user's circumstances, advises on investment, tax, borrowing, or debt, or speculates about outcomes.
The distinction is between explaining what a product does and advising someone on what they should do. A model will drift toward the second if not constrained, because it reads as more helpful.
The correct response to "should I put my savings in the fixed pot or the flexible one?" is that it depends on circumstances, here is factually how each works, and here is how to reach someone qualified.
For anything touching vulnerability, debt difficulty, or financial hardship, route to a human immediately without attempting to help. Those users have specific regulatory protections and a chatbot is the wrong channel.
Data discipline
Keep the chat clear of anything sensitive. No account numbers, no card details, no identity documents, no security credentials, ever.
Configure it to refuse those explicitly, and to redirect anything account-specific to an authenticated session where you know who you are talking to. A bot that cheerfully accepts a card number in an unauthenticated chat window is a security incident waiting to be written up.
The corollary is that it cannot answer account-specific questions. Where is my payment, why was I declined, what is my balance. All of those need authentication and system access. The bot explains the process and hands over.
Support volume, and what it frees
The repetitive layer in fintech support is enormous: how do I reset it, why is it pending, how long does a transfer take, how do I close the account, what does this status mean.
Absorbing that layer does not just reduce cost. It changes what your support team spends its day on. Disputes, fraud reports, complaints, and genuine edge cases are the work that needs judgement, and they currently queue behind the twentieth person asking about verification timelines.
Practical setup
Point it at your help centre, fee schedule, product pages, and onboarding documentation. If the onboarding guidance is thin, write it first, because the bot cannot answer what nobody has documented.
Order the configuration deliberately: regulatory boundary first, data refusal rules second, escalation for vulnerability third, then the content.
Then test it adversarially. Ask it for advice in ten different phrasings. Try to give it a card number. See what it does with "I can't afford my repayment this month". Those tests matter more than the happy path.
What to watch
Verification completion rate is the number that pays for everything else. Track it for users who engaged with the assistant against those who did not.
After that, look at support volume in your top handful of ticket reasons. If both move, the tool is earning its place at the two points where fintech economics are actually decided.