Quick answer: Start in the banker’s world. A useful anchor connects your solution to their pain, recurring task, technology workaround, decision process, or genuine emotion. Choose the anchor for this buyer and validate it in discovery rather than assuming every bank shares the same problem.

Watch the video

23 years of learning: the five anchors

Watch on YouTube if the player does not load.

After 23 years inside Jack Henry and another six years working alongside fintech founders selling their solutions to banks and credit unions, there is one mistake I see over and over again: Fintech founders start the conversation in their world instead of the banker’s.

Bankers wake up thinking about loan growth, net interest margin pressure, deposit mix, staffing shortages, audit findings, board reporting, operational risk, customer expectations, and the limitations they are finding with their existing technology.

Your product might solve one of those problems extremely well, but if the banker has to listen to your pitch and then figure out how your technology connects to something they care about, you have already made the sale harder than it needs to be.

That is why I work with fintech founders on what I call anchors; an anchor roots your solution in something the banker already feels, does, understands, or struggles with.

I generally look for five: pain, task, technology, process, and emotion. Here is how I think about each one.

The important question is this: Which anchor gives this specific banker a reason to care about this specific solution right now?

1. The Pain Anchor: Start With the Cost of the Status Quo

The pain anchor connects your solution to a business problem the institution is already carrying. That could be lost deposits, slow loan growth, abandoned applications, unnecessary labor expense, compliance exposure, poor customer experiences, missed revenue, or something else the institution can see and measure.

The key is that the pain has to be theirs. One of the easiest mistakes to make is walking into a bank with an industry statistic and assuming it describes the institution sitting in front of you.

How to approach the banker through the pain anchor

Instead of opening with:

“Our platform uses advanced analytics to help banks optimize deposit acquisition.”

Try:

“I’ve been talking with banks that are spending more to acquire deposits while still seeing customers move portions of those deposits elsewhere. Is deposit acquisition or retention something your team is actively working on this year?”

Now you have something to discuss. If the answer is yes, go deeper. You are not trying to convince them that they have a problem, you are determining whether the problem you solve is already important enough to deserve attention.

Before positioning your product, understand:

  • What is the problem costing the institution today?
  • Which executive or department owns the problem?
  • How is the institution measuring it?
  • What has already been attempted?
  • What happens if nothing changes over the next 12 months?
  • Is solving it a priority?

A real problem with an owner, measurable consequences, and urgency can become a buying conversation.

2. The Task Anchor: Start With the Work Everyone Hates Doing

Banks are full of processes that technically work but require far too much human effort. Sometimes the strongest anchor is not a major strategic initiative. It is a spreadsheet someone opens every Monday morning.

Employees export data from one system and enter it into another. They reconcile spreadsheets. They manually prepare reports. They chase missing documents. They check exceptions. They maintain processes that have accumulated one workaround after another.

If your technology can eliminate or dramatically improve one of those tasks, start there.

How to approach the banker through the task anchor

Suppose your solution automates a reporting process.

Don't lead with:

“Our platform provides automated reporting and real-time data orchestration.”

Try:

“When your leadership team needs this report today, how does it actually get built?”

Then listen. The banker might tell you that someone exports information from three systems, puts it into Excel, sends it to another employee for review, fixes the errors, and finally turns it into something management can use.

That is your anchor.

You can continue with:

“How often are you doing that?”

Then:

“How many people touch it before it's finished?”

Then:

“If that process went from six hours to 30 minutes, where would that matter most?”

You have moved from selling automation to discussing an actual job happening inside the bank.

Look for:

  • Repetitive data entry
  • Spreadsheet-dependent workflows
  • Manual reconciliation
  • Duplicate work
  • Reports assembled by hand
  • Employees moving information between systems
  • Manual exception reviews
  • Processes dependent on one employee's institutional knowledge

Do not underestimate these problems because they sound operational.

3. The Technology Anchor: Start With the Workaround, Not the Replacement

Bank technology environments are complicated. There is the core. Digital banking. Lending systems. CRM. Payments. Reporting. Compliance tools. Data platforms. Third-party applications.

Then there are the spreadsheets, manual processes, exports, emails, and workarounds connecting all of them.

Founders often look at this environment and immediately see something they could replace. The banker may see technology they cannot replace.

Sometimes the best opportunity is solving what happens between systems.

How to approach the banker through the technology anchor

Don't start with:

“Our technology is a more modern alternative to your current platform.”

That can immediately create resistance.

Instead, try:

“Where does your current technology stop doing what your team needs it to do?”

Or:

“Are there places where your employees are taking information out of the core and putting it into another system or spreadsheet just to complete the process?”

That question can reveal a lot.

Imagine the banker says:

“Yes. We export the data, clean it manually, and then upload it into another system.”

Now your conversation isn't about convincing the institution that its core is inadequate.

It is about a gap the banker already recognizes.

You can ask:

“If you could solve that gap without replacing the systems your team already depends on, would that be worth exploring?”

That is a very different conversation.

Look for:

  • Systems being used for purposes they weren't designed for
  • Employees moving data manually between platforms
  • Spreadsheet workarounds
  • Duplicate systems
  • Missing integrations
  • Legacy processes surrounding newer technology
  • Features the institution owns but cannot practically use
  • Technology limitations that have created operational workarounds

Your technology does not always need to become the center of the bank's technology stack. Sometimes the strongest value proposition is making the stack they already have work better.

4. The Process Anchor: Start With How the Bank Will Actually Buy

This is the anchor I wish more founders understood earlier. You can have an excellent product, a real problem, a successful demo, and an enthusiastic champion and still spend the next six months wondering why nothing is happening.

Banks make technology decisions through a process. Depending on the solution and institution, that process may involve operations, IT, information security, compliance, risk, finance, legal, procurement, executive leadership, and sometimes the board.

Your buyer might love the product and still be unable to buy it without seven other people becoming comfortable with the decision.

That means part of selling to a bank is understanding how the bank buys.

How to approach the banker through the process anchor

After you have established interest, don't simply ask:

“What do you think?”

And don't jump straight to:

“Can I send you a proposal?”

Ask:

“If you decided this was worth pursuing, what would have to happen internally before the bank could say yes?”

That question can change the entire sales process.

The banker might tell you:

“I need to bring in our CIO, then vendor management will need documentation, and anything over this amount eventually needs executive approval.”

Good.

Now you know something.

Follow with:

“Would it make sense to bring the CIO into the next conversation so we can answer the technology questions before you have to carry those answers internally?”

You have just helped your champion move the deal instead of asking them to sell your product for you.

You should understand:

  • Who owns the business problem?
  • Who controls the budget?
  • Who evaluates the technology?
  • Who evaluates vendor risk?
  • Who reviews compliance?
  • Who can stop the purchase?
  • What documentation will be required?
  • When are budgets established?
  • What approval thresholds exist?
  • What happened the last time the institution purchased something similar?

Your CRM might show:

Discovery → Demo → Proposal → Negotiation → Closed

The bank's actual buying process might be:

Business owner → IT → Risk → Security → Finance → Executive team → Contract → Implementation

Those are not the same process. Your sales strategy needs to reflect the second one.

5. The Emotion Anchor: Start With How the Problem Feels

Banking is analytical. It is regulated. Decisions require documentation and justification. But bankers are still human beings. There is usually a person living with the problem your product solves.

Maybe a department leader is embarrassed that her team is still managing an important process in spreadsheets.

Maybe an executive is frustrated because he has asked for better reporting for two years.

Maybe a manager is exhausted because three employees left and the remaining team is carrying the workload.

Maybe a bank president is tired of explaining the same missed target to the board.

Maybe an operations executive had a terrible experience with the last fintech implementation and is now skeptical of every founder promising an easy deployment.

Those emotions affect the conversation.

How to approach the banker through the emotion anchor

You don't ask:

“How does this make you feel?”

This isn't therapy.

You listen for emotion in the language the banker is already using.

Suppose a banker says:

“We've been trying to fix this for two years.”

Instead of immediately explaining your product, stay there.

Ask:

“What has made it so difficult to fix?”

They may say:

“Every solution creates more work for my team, and I don't have the people for another six-month implementation.”

Now you know something extremely important.

Your next presentation should probably not spend 20 minutes on features.

You should address implementation.

You might say:

“Then before I show you much of the product, let me show you what implementation actually requires from your team, because it sounds like that may be more important than another feature comparison.”

That is what anchoring looks like. You listened to what mattered and changed the conversation accordingly.

The Same Fintech Can Be Sold Through Five Completely Different Conversations

This is where founders can make the concept practical. You could approach five bankers about the exact same product in five different ways.

Pain anchor:

“Are you seeing acquisition costs rise while deposit growth remains difficult?”

Task anchor:

“What does your team have to do manually every time one of these accounts comes through?”

Technology anchor:

“Where does your current account-opening technology stop and force your team into another system or spreadsheet?”

Process anchor:

“If you wanted to improve this workflow, who else inside the institution would need to evaluate a new solution?”

Emotion anchor:

“You mentioned your team has been fighting this process for a while. What's been the most frustrating part?”

Same fintech. Five completely different openings. The best one depends on the banker sitting across from you.

How Do You Know Which Anchor to Use?

This is where research and discovery matter. Before your next meeting, do not just research the bank. Develop a hypothesis about the bank.

Look at what leadership is talking about publicly. Look at strategic priorities. Look at hiring. Look at recent technology initiatives. Look at the institution's market. Look at what you learned during the introduction that got you the meeting.

Then write down five questions:

  1. Pain: What business problem might this institution already be paying for?
  2. Task: What manual work might exist because of that problem?
  3. Technology: What system limitation or workaround might be contributing to it?
  4. Process: Who would have to participate if the bank decided to solve it?
  5. Emotion: Who is personally living with the consequences of the problem?

You need a strong enough hypothesis to ask an intelligent question. Then listen.

Stop Making the Banker Translate Your Product

After nearly three decades working at the intersection of banking and fintech, this is one of the biggest differences I see between founders who know how to explain their product and founders who learn how to sell it to banks.

Don't start with what your technology does.

Start with the banker's world.

Then find the anchor.

When the banker feels behind

In a recent post, I described bankers telling me they feel behind as AI and embedded finance change the landscape. That is an observation from conversations, not a claim about every institution. Use it as a discovery hypothesis: ask what this banker is trying to keep up with and where that concern affects their work. The emotion anchor only works if the feeling is real. Naming an anxiety you have not confirmed is pressure, not understanding.

Frequently Asked Questions

What is an anchor in fintech sales?

An anchor connects your fintech solution to something the banker already recognizes: an existing business pain, a manual task, a technology limitation, an internal buying process, or the human impact of a problem.

The purpose is not to create pain or manufacture urgency. It is to understand where your solution connects to a priority that already exists inside the institution.

Which anchor should I use when approaching a bank?

There is no universally correct anchor.

Choose the one supported by what you know about the institution and the person you are approaching.

A CFO may respond to a measurable financial pain differently than an operations executive dealing with a manual workflow. A CIO may be more interested in a technology limitation or integration problem. A line-of-business executive may care most about the business outcome.

Your job is to find the relevant entry point rather than force every prospect through the same pitch.

Should I use all five anchors in the same sales conversation?

Usually not. The anchors are a diagnostic framework, not a five-part pitch. One anchor may open the conversation. Discovery may uncover another. As the opportunity moves through the institution, different stakeholders may care about different anchors.

What if I don't know enough about the bank to identify an anchor?

Don't invent one. Use your industry knowledge to form a hypothesis and turn the hypothesis into a question.

Instead of saying:

“You're losing deposits because your digital experience is outdated.”

Ask:

“Are you seeing any relationship between digital account-opening friction and your deposit-growth goals?”

One assumes.

The other discovers.

Can the anchor change during the sales process?

Absolutely. You might enter through a task problem that gets an operations executive's attention and later discover that the stronger executive-level argument is financial pain.

You may then need a technology anchor for IT and a process or risk conversation for vendor management.

The business problem can remain the same while the relevance changes by stakeholder.

Sources

Continue the conversation

For help translating your product and sales process into a bank-ready decision, explore working with Stacy. For ongoing practical guidance, subscribe to Selling Fintech.

Adapted from Stacy Bishop’s original posts and newsletter with AI-assisted editing. Cover portraits were generated from Stacy’s reference photographs. Illustrative exercises are labeled.