Insights on fintech, banking & partnerships

Quick answer: When a bank goes quiet after a strong sales call, the founder should diagnose the internal stall before pushing harder. Silence may mean the champion lacks language, the product has no clear owner, risk or IT raised concerns, urgency is weak, the business case is incomplete, or the next step was too vague. The right follow-up should help the bank resolve the stall, not simply ask for an update.

A bank sales call can feel strong and still go quiet.

The banker was engaged. The questions were thoughtful. The problem seemed real. The founder left the meeting confident.

Then nothing.

No next meeting. No clear objection. No hard no.

Just silence.

Founders often read that silence as disinterest. Sometimes it is. But often, something happened inside the bank that the founder cannot see.

The worst response is to keep sending generic check-ins.

“Just following up” does not solve an internal stall.

Diagnose before you push

Before you follow up, ask what may have stalled.

There are six common possibilities.

1. The champion did not have the language

Your champion may have tried to explain the product internally and struggled.

If the product requires too much translation, the champion can lose confidence.

The fix is not another demo. The fix is clearer language, a tighter problem statement, and a forwardable summary.

2. No one owned the problem

The banker may like the idea but not know where to route it.

If the product does not clearly belong to an internal owner, the bank has no natural path for the decision.

Your follow-up should help identify the likely owner and suggest who should be involved next.

Quick answer: A board-ready business case helps a bank explain why buying now is sensible, safe, and worth the cost. It should connect the problem to measurable impact, show who owns the decision, define implementation effort, address risk, compare the cost of waiting, and give leadership a defensible next step.

In many bank deals, the founder sells the product and forgets the decision.

The banker may understand the product. The business owner may like it. The team may agree the problem is real.

But someone still has to justify the purchase.

That person may need to explain the decision to executive leadership, finance, a steering committee, or the board.

If you do not help them build that case, you leave the most important internal conversation under-supported.

A business case is not a feature list

A feature list says what the product does.

A business case explains why the bank should act.

Those are not the same thing.

Banks do not approve change because a product has useful features. They approve change when the institution can see the problem, the cost of the current state, the risk of acting, the risk of waiting, and the path to implementation.

Your job is to connect those pieces.

Start with the cost of the current state

The strongest business case begins with the cost of the problem continuing.

That cost may show up as:

• Staff time

• Manual review

• Exception volume

• Fraud loss

• Compliance exposure

• Customer friction

• Missed revenue

• Vendor inefficiency

• Operational drag

Use the bank’s language and measures where possible.

If you cannot quantify the cost exactly, define the category of cost clearly. Vague pain does not create urgency.

Show why now matters

Banks can agree that a problem is real and still wait.

Timing pressure matters.

The business case should explain why waiting has a cost. That cost might come from examiner attention, customer experience, staff capacity, contract renewal, leadership priority, competitive pressure, or a current process that is becoming unsustainable.

If there is no reason to act now, the bank may keep the conversation alive without moving it forward.

Quick answer: To make implementation feel realistic to a community bank, fintech founders must explain the first phase, internal resource requirements, data and system touchpoints, support model, timeline, risk review, and what the bank does not have to do. Community banks are often interested in innovation, but they buy when the lift feels manageable.

Community banks do not reject fintech because they dislike innovation.

Many are actively looking for better ways to serve customers, reduce manual work, improve efficiency, and compete with larger institutions.

But interest is not the same thing as capacity.

A community bank may like your product and still hesitate because the team is thinking:

Who is going to implement this?

That question can stall a deal if the founder does not answer it clearly.

Lean teams evaluate lift early

A large bank may have dedicated teams for innovation, vendor management, procurement, information security, project management, compliance, implementation, and operations.

A community bank may have a much smaller group of people wearing several of those hats.

That changes the buying conversation.

The bank is not only evaluating the value of the product. It is evaluating whether the organization can absorb the work.

Explain the first phase

Do not describe implementation as one large event.

Break it into phases.

The first phase should answer:

• What happens first?

• Who needs to participate?

• What information is needed?

• What systems are involved?

• How long does it usually take?

• What does success look like at the end of this phase?

When implementation is phased, it feels more manageable.

Quick answer: Fintech founders should treat bank risk, IT, and compliance questions as normal review signals, not personal criticism. The strongest answers acknowledge the concern, explain the relevant control or limitation, show what documentation is ready, and clarify what the bank should evaluate next.

When a bank asks hard questions, some founders hear rejection.

They hear:

This is risky. This will take too much work. Compliance will not like this. IT needs to review it.

Then they start defending the product.

That is usually the wrong move.

In bank sales, risk, IT, and compliance questions are not automatically bad signs. They often mean the bank is trying to understand whether the opportunity can move through its process.

The founder’s job is to make that process feel clearer, not to argue with it.

Do not fight the review process

Banks are regulated institutions. They cannot skip vendor review because they like the founder or believe the product is innovative.

When a bank asks about data, controls, implementation, business continuity, access, customer impact, or vendor oversight, it is not inventing friction for fun.

It is doing the work the institution is expected to do.

Founders lose credibility when they act annoyed by that.

A better posture is:

That is exactly the right question. Here is how we usually handle it.

That one sentence changes the tone of the conversation.

Use a four-part answer

A strong answer has four parts:

1. Acknowledge the concern.

2. Explain the relevant control, limitation, or process.

3. Point to the documentation or evidence.

4. Clarify the next evaluation step.

Example:

Data access is the right place to start. In this use case, we do not need direct access to core transaction history. We would need [specific data or system touchpoint]. We have documentation that explains data handling, retention, access controls, and implementation responsibilities. The best next step would be to bring in information security so we can confirm fit before anyone scopes the pilot.

That kind of answer lowers the temperature.

Risk wants clarity, not performance

Founders often over-explain when risk enters the conversation.

They try to prove the product is safe by talking more.

Risk teams do not need a performance. They need clarity.

They want to know:

• What does the product touch?

• What does it not touch?

• What happens if something fails?

• Who is responsible for what?

• What evidence can the bank review?

• What ongoing monitoring would be required?

Answer those questions directly.

Quick answer: The best first use case for a bank pilot is narrow, owned, measurable, urgent, and operationally realistic. It should solve a real bank problem without requiring the institution to redesign too many processes at once. Founders weaken first deals when they try to prove the entire platform instead of one decision-ready use case.

Your first use case inside a bank should not be the biggest possible version of your product.

It should be the easiest meaningful version to approve.

That distinction matters.

Founders often want the bank to see the full vision. They want to show every capability, every workflow, every future expansion path.

I understand why.

But inside a bank, a broad first use case can create more risk than momentum.

The bank is not only asking whether the product is useful. It is asking whether this first step is safe, clear, and manageable.

Choose a problem someone owns

The first use case needs an internal owner.

If no one inside the bank clearly owns the problem, the deal will drift.

Ownership matters because someone has to sponsor the evaluation, answer internal questions, coordinate stakeholders, defend the business case, and push the next step.

If your use case touches five departments but belongs to none of them, it may sound strategic and still go nowhere.

Choose a problem the bank can measure

A pilot should create evidence.

That evidence might be reduced manual time, fewer exceptions, faster review, better completion rates, lower error volume, stronger visibility, improved customer experience, or clearer compliance oversight.

If the bank cannot measure the improvement, the pilot becomes subjective.

Subjective pilots are harder to turn into contracts.

Choose a problem with enough urgency

Useful is not enough.

The bank has to care now.

Look for timing pressure:

• Audit findings

• Staffing constraints

• Vendor renewal

• Board priority

• Customer complaints

• Operational backlog

• Fraud exposure

• Compliance concerns

• A strategic initiative already in motion

The best first use case connects to a clock the bank already watches.

Quick answer: A bank pilot converts when it is designed around a commercial decision before it starts. Founders should define the buying question, success criteria, scope, timeline, internal owner, stakeholder review process, and contract path upfront. If the pilot is vague, the bank may learn something useful and still never buy.

A pilot can feel like a win.

The bank said yes. The team is testing the product. People are engaged. The founder finally has a real institution using the solution.

But a pilot is not a contract.

I have seen fintech pilots create a lot of activity and no decision. Everyone stays friendly. Everyone learns something. The product may even work.

Then the pilot ends and nothing happens.

That is usually not because the pilot failed technically. It is because the pilot was never designed to answer a buying question.

Put a decision at the center of the pilot

Before a bank pilot starts, the founder should be able to answer one question:

What decision will the bank make at the end of this?

If the answer is vague, the pilot is already in danger.

“They want to test it” is not enough.

Test it for what?

To decide whether to expand? Replace a current process? Approve a budget? Bring in risk? Move to contract? Choose between vendors? Build a business case?

The decision has to be named.

Define success before the work starts

Many pilots fail because success is discussed only after the pilot is already running.

That creates room for drift.

The founder thinks success means the product worked. Operations thinks success means staff did not complain. The executive sponsor thinks success means measurable savings. Risk thinks success means no new exposure. Finance thinks success means the business case is strong enough.

Those are not the same standard.

Define success upfront.

A practical success statement might sound like this:

At the end of the pilot, the bank will decide whether the solution reduces manual review time enough to justify a paid rollout for [department/use case], subject to standard vendor review and final commercial approval.

That statement gives the pilot a purpose.