conversational banking for credit unions: what it is, what members actually use, and how to evaluate it

Most 'conversational banking' demos are a chatbot bolted onto a login page. Members do not want to log in to ask a question. Here is what the category looks like when it works, and how a credit union should evaluate it.

Every digital banking vendor now sells something called conversational banking. The phrase covers a lot of ground: an FAQ bot in the mobile app, a voice assistant in the IVR, an Alexa skill nobody enabled, and, more recently, an AI assistant that can read a member's accounts and answer in plain English. A head of digital at a credit union has to tell those apart, because they cost about the same to buy and deliver wildly different results.

This guide is written for that person. It defines the category from the member's side rather than the vendor's, lists the requests that actually make up the volume, explains why the channel matters more than the model, and ends with the questions to ask before a pilot. Flip is one of the vendors in the space, and we say so where it is relevant, but the evaluation checklist applies to anyone.

That definition rules out most of what is sold under the name. A scripted bot that answers 'what are your branch hours' is a search box with a chat skin. A voice menu that says 'press one for balances' is an IVR. Neither reads the member's accounts, and neither can do anything about what it finds.

The bar that matters has three parts. The assistant understands a question phrased the way a person actually phrases it ('did my paycheck hit yet'). It answers from the member's real data, not a knowledge base. And it can take the next step when the member asks for it, whether that is setting a reminder, moving money into savings, or cancelling a subscription, with the member's approval. Anything less is a help center.

Credit unions that have run a text or chat channel for a while tend to report the same pattern: a handful of request types account for the large majority of conversations. These are the ones an assistant must handle well, in roughly the order members ask them.

1. Balance and 'is it safe to spend' questions, usually phrased around a specific purchase or a specific date.
2. Did a deposit land, and when will the next one.
3. What is this transaction, and why is it a different amount than last month.
4. Upcoming bills and whether there is enough to cover them before payday.
5. Subscriptions and free trials: what am I paying for, and cancel this one.
6. Move money between my own accounts, including into savings or a certificate.
7. Pay a person, split a cost, or request money from someone.
8. Card questions: is my card locked, was this charge me, dispute this.
9. Loan and credit questions: payoff amount, next payment, what rate would I get.
10. Set a reminder or a rule ('tell me when my balance drops under $200').
11. Spending summaries: how much on food this month, am I over last month.
12. Reach a human, usually after one of the above turned out to be complicated.

The single biggest predictor of whether a conversational channel gets used is how many steps stand between the member's question and the first message. An in-app chatbot requires the member to find the app, log in (often with a second factor), find the chat icon, and then type. By the time they get there, the question that prompted the whole thing has often been answered by looking at the balance screen.

A text channel has zero steps. The member opens Messages, the thread is already there, and they type. The same channel also works in the other direction: the assistant can speak first when a paycheck lands or a bill is about to overdraw, and the member sees it in the same place they see texts from family. Push notifications from a banking app are muted on a large share of phones; texts are not.

A member who learns their checking balance is lower than they thought wants to do something about it: move money from savings, delay a payment, cancel the thing that caused it. An assistant that can only answer sends them back to the app to act, which is exactly the friction it was supposed to remove.

This is also where a credit union's risk team gets nervous, correctly. The right model is that the assistant drafts and the member approves. A transfer is proposed in the thread with the amount, the accounts, and the date; the member confirms with a passkey or biometric; the approval is logged alongside the action. The assistant never moves money on its own authority, and the credit union configures which actions are allowed and at what dollar thresholds.

The fastest path to a pilot is read-only account access through an aggregator the credit union already works with (Plaid is the common one), or through the aggregator's existing connection to the core. That gets balances, transactions, and recurring charges without a core project. A direct core integration (Symitar, Corelation KeyStone, Fiserv DNA, and the rest) comes later, once the pilot has proven the channel is worth it and the data needs are known.

Two things to insist on regardless of the path: the vendor never stores member credentials, and access is read-only by default with write actions enabled individually by the credit union. Ask to see the consent flow the member goes through, and ask who holds the token.

• Show me a member asking 'can I afford $400 on Thursday' with a real linked account. What does the answer include?
• Which of the twelve common requests above can it complete, not just answer?
• Does it work by SMS and iMessage, or only inside our app?
• Can it message first? What triggers that, and how does the member control it?
• What exactly happens when it does not know? Show me the hand-off to a person.
• How does it get account data, who holds the credentials, and is access read-only by default?
• Which actions move money, and what approval does each require?
• Can we set dollar limits and disable actions per institution?
• Is every action logged with the approval that authorized it? Can we export that log?
• Can it run under our brand and our phone number?
• When it suggests a savings move, does it name our products or a third party's?
• What does a 90-day pilot cost, and what numbers do we get weekly?
• What is the per-member price after the pilot, and is there a floor?
• Will you complete our vendor due diligence questionnaire and share a SOC 2 or equivalent?
• Who are two credit unions or banks we can call?

A pilot should be a few thousand members at most, invited directly, with a control group of similar members who were not. Measure adoption (how many texted at least once, how many are still texting at week eight), resolution (what share of conversations ended without a hand-off), deposits (dollars moved into the credit union's savings and certificate products through the assistant), and contact-center deflection (inbound volume from the pilot cohort versus control). Ninety days is enough to see all four.