The safe way to handle AI agents contacting fintech support is to serve them with rules: answer general questions openly, give the agent the customer's authority and no more, require the same identity verification a human gets before anything account-specific happens, and rate-limit instead of banning. Blocking them outright usually means blocking your own customers.
Personal AI agents now research, compare, switch, cancel and contact support for the people who use them. They do it in chat, over email, through site forms and increasingly over the phone. For a fintech, that traffic lands on the most sensitive parts of the business: logins, one-time codes, identity checks, disputes, fees, cancellations and collections. This is the practical side of B2A (business to agent): the same customers you already serve, arriving through a new channel that behaves like software.
Below are the seven places fintech support breaks first when agents show up, why each one breaks, and the fix. Regulation is covered in general terms only. Nothing here is legal advice, and any specific obligation you rely on should be confirmed with your compliance team.
Key takeaways
Agents are customers on a new channel. A personal agent acting for a real account holder deserves an answer, not a ban. Treat bot farms and verified agents differently.
Anonymous by default, verified before action. An unverified agent can get the same public answers your website gives. Balances, disputes, plan changes and anything account-specific wait for identity verification.
The customer's authority and no more. An agent can never do something the customer could not do themselves, and it should never be a route around your authentication.
Stale scrapes are a compliance risk. If agents quote your fees and rates from an old cached page, your customers get wrong information in your name. Give them a sanctioned source instead.
Rate limits beat bans. Agents poll. Cap the volume, tell them when to check back, and make sure a retry never opens a second ticket.
One concierge, one set of policies. The agent should reach the same knowledge, workflows and guardrails your human customers get, and every conversation should land as a normal ticket you can audit.
Why fintech support feels agent traffic first
Agents go where the money is, and so do their users. The public examples so far are overwhelmingly financial: one user asked an agent to shop for cheaper car insurance while at the gym and reported "15 min later I'm saving $1156 a year." Another agent bound a policy the same day: "The Progressive policy is bound. Policy is effective at 6pm today." Instinct's founder lists "cancelled hundreds of dollars of subscriptions" as a top use, and one user's agent took a bill from $80 to $40 a month, plus three months free. These examples come from our own write-up, Personal agents are coming. No one is ready.
Each of those jobs, whether it is comparing rates, switching providers, cancelling, disputing or negotiating a bill, ends in a support conversation with a financial company. Fintech support teams were built around a person at a keyboard or on a phone, with fraud controls tuned to catch anything that behaves like a script. A personal agent behaves exactly like a script, because it is one, and it is also acting for a real customer with a real account.
That tension is the whole problem. Your fraud stack is right that the traffic is automated. It is wrong about what that means. If you want the broader argument for serving rather than blocking, read blocking vs serving AI agents. What follows is the fintech-specific version: the seven places things go wrong.
1. Account access and one-time codes
What breaks
An agent is asked to check a payment, update a direct debit or download a statement. It tries the customer's saved password. That fails, or hits a device check, so it looks for another way in. The public record already has one: an agent that couldn't sign in with a saved password used the one-time-code path instead, as its user put it, "read the code from your Gmail, signed in as you".
Why it breaks
Agents are built to finish the task. When the front door is locked, they find the side door, and in most fintech products the side door is the password reset or one-time code flow. From your side this looks exactly like account takeover: repeated failed logins, then a code request, then a code entered in seconds from an unfamiliar environment. Your fraud tooling flags it, and it should, because an attacker would produce the same pattern.
The fix
Give agents a sanctioned place to ask. Most of what an agent wants before logging in is general: how do I change my repayment date, where do I find my statement, what does this fee mean. A public, agent-facing support endpoint answers those without the agent ever touching your login.
Never let the agent become an authentication bypass. The agent gets no more access than the customer has already proven. Account-specific answers require the same identity verification a human would pass on chat or phone.
Write one-time-code messages for the agent era. Say plainly what the code is for and what it authorizes. A customer whose agent reads their inbox should still be able to see that a code was used to reset a password rather than to view a balance.
Keep the fraud flag, change the response. Treat the pattern as a signal to step up verification and route to a human, not as proof of fraud that ends in a closed account.
2. KYC and identity verification
What breaks
An agent tries to open an account, complete onboarding or clear a verification hold on the customer's behalf. It asks what documents are needed, then attempts to submit them, answer security questions or reschedule a video check.
Why it breaks
Know-your-customer obligations sit with your firm, and they exist to confirm a specific human is who they say they are. An agent can hold a copy of a passport photo and fill a form perfectly, which is precisely why its submission proves nothing about the person. Meanwhile, the questions the agent asks along the way are completely reasonable ones, and refusing to answer them just pushes the customer to a competitor whose support will.
The fix
Split explaining from verifying. Agents should get clear, accurate answers about what documents you accept, how long checks take and why a hold might happen. The verification step itself stays with the customer, in your existing flow.
Hand back, don't dead-end. When the agent reaches a step only the customer can do, tell it so in plain language and give it the link or instruction to pass on. A good agent will relay that to its user.
Reuse your existing identity skills. The verification an agent triggers should be the same one your concierge already applies on chat, email and voice, not a separate, weaker agent path.
If you are reviewing how your support stack handles identity more broadly, our guide to AI support with KYC and identity verification covers the options.
3. Disputes and chargebacks
What breaks
A customer tells their agent a charge looks wrong. The agent files a dispute by chat, then by email, then through the web form, and retries when it doesn't get an instant reply. You now have three tickets for one dispute, with slightly different wording, and nobody is sure which one started the clock.
Why it breaks
Disputes carry deadlines. In the US, for example, Regulation E's error resolution rules for electronic fund transfers set out timeframes that run from when the institution receives the consumer's notice of error, including a 10 business day investigation window in the standard case (see 12 CFR 1005.11 on the CFPB site). Card networks and other jurisdictions have their own rules. Whether a message from a customer's agent counts as the customer's notice is a question for your counsel. Operationally, the safe assumption is that it could, which means duplicate, unlinked tickets are a real risk rather than an annoyance.
The fix
One dispute, one ticket. Deduplicate agent retries so a second attempt updates the existing conversation instead of opening a new one.
Record receipt precisely. Capture when the first message arrived and on which channel, so your team can apply whatever deadline rules your counsel says apply.
Explain the process, verify before acting. An unverified agent can learn how disputes work and what information is needed. Filing against a specific transaction waits for identity verification.
Keep the decision with your disputes team. The concierge can gather details and confirm receipt. The outcome stays with the humans and systems that own it today.
4. Fees and rates answered from stale scrapes
What breaks
An agent comparing lenders or accounts reads a cached copy of your pricing page from months ago, or a third-party comparison site, and tells its user your rate, fee or eligibility criteria. The number is wrong. The customer arrives expecting it, or never arrives because a competitor looked cheaper.
Why it breaks
Agents answer from whatever they can reach. If your current terms sit behind a calculator, a login or a bot wall, the agent falls back to older copies elsewhere on the web. In financial services, a wrong rate quoted in your name means a customer was misinformed about a financial product, and the complaint will land with you.
The fix
Publish a sanctioned answer source. A public endpoint that answers from your current knowledge gives agents a better option than scraping. Point to it from your site and from an llms.txt file (a proposed convention for telling agents what you offer). Our comparison of WebMCP, public endpoints and llms.txt explains when each fits.
Answer with the conditions attached. Representative rates, eligibility and "subject to status" caveats belong in the agent's answer the same way they belong on your website.
Keep facts in one place. The concierge that answers agents should answer from the same knowledge that answers human customers, so a fee change updates both at once.
Stop blocking the crawlers you want. Check that your security settings aren't hiding current pricing pages from the agents your customers use. The agent-ready website checklist walks through this.
5. Cancellations and retention
What breaks
Agents are good at cancelling things. A customer asks their agent to close an account, cancel a subscription tier or stop a card, and the agent runs straight into a retention flow designed for a human: a save offer, a survey, a "call us to cancel" instruction. The agent either loops, escalates on every channel at once, or reports back to its user that you made cancelling hard.
Why it breaks
Retention flows were tuned for human hesitation. An agent has none, and it will describe friction to its user exactly as it experienced it. For regulated firms there is also a conduct angle: in the UK, for example, the FCA's Consumer Duty sets high standards for putting customers' needs first. Your compliance team will have a view on what a fair cancellation journey looks like, and it should apply whether the customer arrives in person or through an agent.
The fix
Make the cancellation path explicit. Tell the agent exactly what is needed to cancel and how, in one answer.
Offer once, clearly. If there is a genuine better deal for the customer, state it once in terms the agent can relay. Agents are already negotiating on price, so a real offer gets passed on and a vague one gets ignored.
Confirm with the customer before the irreversible step. Closing an account or cancelling a product is an action. It requires verification and, where your policy demands it, a confirmation the customer sees.
Watch the topics behind cancellations. If agent cancellations cluster around one fee or product, that's product feedback your support data should show you.
6. Collections and hardship
What breaks
A customer behind on repayments asks their agent to sort it out. The agent contacts your collections team to negotiate a payment plan, dispute a late fee or ask for a pause. Agents already do this with other providers: one user's agent "went to war with AT&T over the phone bill".
Why it breaks
Collections and hardship are among the most sensitive conversations a lender has. Your team is trained to listen for signs of vulnerability, give required information about options and support, and agree arrangements the customer can actually keep. An agent strips out the tone of voice and the pauses your team relies on, and it may accept or propose an arrangement the customer never saw. A hardship conversation run as a price negotiation is a bad outcome for everyone.
The fix
Answer the general questions openly. What hardship options exist, how to apply and what happens to fees are all things an agent should be able to learn without verification, the same as reading your help center.
Verify and confirm before any arrangement. A payment plan, a fee waiver or a pause is an action on the account. It needs identity verification and the customer's own confirmation of the terms.
Route vulnerability signals to a human. If the agent's message mentions illness, job loss, bereavement or financial distress, escalate to a trained person the same way you would on a phone call.
Keep your policies the same. The agent gets the same options a human customer would get, no better and no worse.
7. Volume and polling
What breaks
Agents check. Is the refund through yet? Has the rate dropped? Is the payout processed? A human asks once and waits. An agent asks every few minutes, across channels, until it gets an answer.
Why it breaks
The clearest public example is from outside fintech. In September 2026 Resy deactivated a user's account after his agent, Instinct, sent about 200 API requests an hour, polling every 10 minutes and every 0.4 seconds around the daily table release. In his words: "Of course, this account got flagged for spam, because it was acting like a bot." Resy reinstated the account two days later. Swap tables for payout status or a rate-drop alert and the same pattern hits a fintech queue: the traffic is real and the customer is real, but the volume looks like an attack.
The fix
Rate-limit the channel, not the customer. Cap requests per conversation and per key so volume stays manageable without closing anyone's account.
Tell the agent when to check back. If a refund takes three to five business days, say so in a form the agent can act on. An agent that knows when to return has no reason to poll.
Make retries idempotent. A repeated question should continue the existing conversation. It should never open a second ticket.
Separate good agents from bot farms. Keep bot management for credential stuffing and scraping at scale. Give personal agents a sanctioned channel so they don't have to look like attackers to get an answer.
Summary: problem, risk and fix
Problem | Risk | Fix |
|---|---|---|
1. Account access and one-time codes | Agent behavior looks like account takeover; agent used as an authentication bypass | Sanctioned endpoint for general questions; same identity verification before anything account-specific; clearer code messages |
2. KYC and identity | Documents submitted by software prove nothing about the person | Agents get explanations; verification stays with the customer in your existing flow |
3. Disputes and chargebacks | Duplicate tickets and unclear receipt time against deadline rules | One dispute, one ticket; timestamp first receipt; verify before filing against a transaction |
4. Fees and rates from stale scrapes | Customers misinformed about financial products in your name | Public answer source from current knowledge, with conditions attached; don't hide pricing from agents |
5. Cancellations and retention | Friction reported back to the customer; conduct concerns | Explicit path, one clear offer, verification and confirmation before irreversible steps |
6. Collections and hardship | Arrangements agreed without the customer; vulnerability missed | General info openly; verify and confirm any arrangement; route vulnerability signals to humans |
7. Volume and polling | Real customers banned as spam; queue flooded | Rate limits, check-back instructions, idempotent retries, bot management kept for real bots |
The six rules under every fix
Read the seven fixes together and the same rules keep appearing. They make a workable operating policy for agent traffic in any regulated support team.
Serve with rules. Answer agents instead of blocking them, and publish the rules they have to follow.
The customer's authority and no more. An agent can do what the verified customer could do, and nothing beyond it. It sees only what a customer would see.
Step-up verification before any action. Anonymous agents get public answers. Anything account-specific triggers the same identity verification a human would pass.
Rate limits and check-back. Cap volume, tell agents when the answer will be ready, and make sure retries don't create duplicate work.
Same concierge, same policies. One source of knowledge, one set of workflows and guardrails, across chat, email, voice and agents. No separate, weaker bot FAQ.
Ticket visibility. Every agent conversation lands as a normal ticket, sorted by topic, so your team and your auditors can see what happened.
A note on regulation
Most financial regulation predates personal agents and does not mention them. What it does cover, in most jurisdictions, is who the customer is, what they were told, what they authorized and how quickly you responded. Those questions don't change when an agent is in the middle; they get harder to answer if you have no record of the agent conversation.
Some rules already anticipate third parties acting for consumers. In the US, the CFPB's personal financial data rights rule under section 1033 addresses making data available to consumers and authorized third parties, and the CFPB has opened a reconsideration of parts of it, including how a consumer's "representative" is defined. That rule is about data access rather than support conversations, but it signals the direction: regulators expect consumer-authorized access to be possible and controlled, not banned.
The practical point for a support leader: design for auditability. If you can show which conversations were anonymous, which were verified, what the agent was told and what actions were taken on whose authority, you are in a far better position to answer whatever your regulator asks. This is general information, not legal advice. Your compliance team and counsel should decide how the rules that apply to you treat agent-initiated contact.
How Lorikeet handles AI agents in fintech support
Lorikeet builds AI customer support for complex and regulated businesses, including fintech, healthtech and insurance. Lorikeet B2A, launched in September 2026, gives personal agents a sanctioned front door to the same AI concierge that already answers your customers on chat, email and voice.
Two ways in, one concierge. Agents that support WebMCP, a proposed web standard, call tools registered on your website. Every other agent calls a public endpoint in plain HTTP and gets plain JSON back, with instructions for follow-up questions in the same conversation.
Same brain as customer service. The agent reaches the same knowledge, workflows and actions as your human customers, so a question about a fee and a question about a repayment date get the same answer whichever way they arrive.
Governed. Agents get no more authority than the customer. Endpoint conversations are anonymous by default, and anything account-specific uses the same identity verification skills and policies the concierge applies on other channels.
Built for machine traffic. An agent asks, then checks back for the answer. Rate limits cap the volume, and a retry does not open a second ticket.
Visible. Every agent conversation lands in Lorikeet as a normal ticket, sorted by topic, so you can see what agents are asking for and audit what they were told.
No backend work. The concierge answers from your existing knowledge.
Setup takes four steps:
Create an account.
Coach helps you build and test a concierge for your website.
Turn on the agent-facing endpoint.
Paste the snippet Coach gives you into your website.
Consumer lenders are already thinking about this. Amy Rushby, Co-Founder and Director of Product and Operations at Carmoola, a UK car finance company, put it this way on our launch post:
"Carmoola is car finance your way. You know your budget before you shop, and you manage everything in the app with no paperwork and no sales calls. More people now want their own AI agent to do that shopping and managing for them. If that's how a customer wants to do it, it should be just as fast, fair and simple as the app. That's why we're preparing for business to agent now with Lorikeet."
The concierge underneath B2A is the same one fintech teams use for human support. Hnry, for example, went live in mid-May 2026 and handled 17,000+ conversations in its first month. For the wider picture of AI support in financial services, see our guide to AI customer support for fintech, and if you want to check whether agents are already in your queue, start with the seven signs AI agents are contacting your support team.
You can test this on lorikeetcx.ai itself: the site runs a public agent endpoint and an llms.txt file that points agents to it.
Talk to us
If agents are already showing up in your queue, we should talk. We'll show you how the concierge answers them, where verification kicks in and what the tickets look like on your side. Get a demo.
