The deal was progressing beautifully. Your business champion was excited, the demos impressed stakeholders, and procurement conversations had started. Then Risk Management asked to meet.
Two weeks later, the momentum is gone. Your champion is apologetic but vague. “Risk has some concerns we need to work through.” Translation: your deal just entered an indefinite holding pattern, and there’s a strong possibility it never recovers.
If you’re selling technology to banks, this scenario is depressingly familiar. Risk is the silent deal-killer in financial services sales. They rarely say no explicitly—they just raise questions that never get satisfactorily answered, creating enough uncertainty that deals quietly die.
Here’s what most fintech salespeople don’t understand: Risk teams aren’t being obstructionist. They’re doing exactly what they’re supposed to do. And once you understand their mandate and incentives, you can work with them instead of against them.
Why Risk Management Exists
Risk Management in banks isn’t a advisory function that provides input on decisions. It’s an independent control function with explicit authority to prevent the bank from taking unacceptable risks.
This distinction matters enormously.
Control functions don’t report to the business lines they oversee. They report separately to the board or CEO. This independence is required by regulators specifically so business enthusiasm doesn’t override prudent risk management.
What does this mean for you? Your business champion can’t overrule Risk, even if they’re more senior. Risk has independent authority to say “we’re not comfortable with this” and that’s often the end of the conversation.
What Risk Teams Are Actually Measured On
To understand why Risk behaves the way they do, you need to understand their incentives.
Risk professionals are measured on what doesn’t happen:
- Operational failures that disrupt services
- Vendor failures that create business continuity issues
- Security incidents that compromise data
- Regulatory penalties resulting from poor oversight
- Reputational damage from vendor problems
Their success is invisible. When nothing goes wrong, they’re doing their job. But when something goes wrong, particularly with a vendor they approved, they’re personally accountable.
This creates strongly conservative incentives. Saying yes to a new vendor creates potential downside risk with limited upside. Saying no (or indefinitely delaying) creates no downside.
The career calculus is simple: approving a vendor that later fails is career-limiting. Not approving a vendor that might have worked is barely noticed.
The Questions Risk Wants Answered (But Often Doesn’t Ask Directly)
When Risk meets with vendors, they’re evaluating several dimensions simultaneously. Often they don’t articulate these clearly, which is why vendors struggle to address their concerns.
Here are the real questions running through their minds:
Operational resilience: “If this vendor’s service fails, what’s the impact on our operations? Can we continue functioning? How long until recovery?”
Vendor viability: “Will this company still exist in three years? What happens if they get acquired? What if they run out of money? Do we have exit rights?”
Concentration risk: “Are we becoming too dependent on this vendor? Do they have other bank clients who could be affected by the same issue? Are we their largest client?”
Control environment: “Does this vendor operate with adequate controls? Are they mature enough to operate in a regulated environment? Will they respond appropriately to incidents?”
Information security: “What data will they access? Where will it be stored? Who else has access? What happens in a breach scenario?”
Third-party dependencies: “Who does this vendor depend on? If their subprocessors fail, does that affect us? How many layers of dependency are we creating?”
Regulatory exposure: “Could this vendor create regulatory issues for us? Will regulators question this relationship? Can we demonstrate adequate oversight?”
Notice what’s absent from this list: product features, ROI, customer experience improvements. Risk doesn’t care about those things. That’s Business’s job. Risk cares about what could go wrong and whether the bank can manage those scenarios.
Why “That’s Unlikely” Is the Wrong Response
When Risk raises concerns about failure scenarios, the instinctive vendor response is to minimize: “We’ve never had that problem.” “Our uptime is 99.9%.” “That’s extremely unlikely.”
These responses make Risk more concerned, not less.
Why? Because Risk’s job is to plan for low-probability, high-impact scenarios. Telling them something is unlikely doesn’t address their concern—it signals you haven’t thought through tail risk.
Better responses acknowledge the scenario as legitimate, demonstrate you’ve thought through it, and explain your mitigation approach:
“That’s a legitimate concern. Here’s what we’ve built into our architecture to prevent that scenario. If it did occur despite those controls, here’s our recovery process and timeline. And here’s the compensation mechanism if we fail to meet those commitments.”
This response tells Risk you take their concerns seriously, you’ve planned for failure modes, and you have accountability mechanisms. That’s what they need to hear.
The Documentation Risk Needs (That Most Vendors Don’t Provide)
Risk teams need to demonstrate to auditors and regulators that they conducted adequate due diligence on vendors. This requires documentation that most startups don’t naturally produce.
Here’s what Risk typically needs to see:
Business continuity and disaster recovery plans: Detailed documentation of how you handle failures, recovery time objectives, backup systems, and testing procedures.
Information security policies and procedures: Not just certifications, but actual documented processes for access control, data protection, incident response, and security monitoring.
Financial stability evidence: Recent financial statements, funding status, burn rate projections, and major investor information. They need to assess whether you’ll still exist in two years.
Vendor risk management framework: Your process for managing your own third-party dependencies. If you rely on AWS, what’s your monitoring and incident response process?
Operational resilience testing: Evidence that you actually test your disaster recovery plans and document the results. Claims without evidence don’t satisfy Risk.
Insurance coverage: Relevant policies including cyber liability, errors and omissions, and general liability with adequate coverage limits.
Incident history and response: Past incidents, how you handled them, what you learned, and what you changed. A clean record raises suspicion—everyone has incidents. How you handle them is what matters.
Exit planning: How the bank can transition away from your service if needed. What data portability exists? What’s the typical exit timeline? What support do you provide?
Most startups don’t have all this documentation prepared. When Risk requests it, vendors scramble to create it, signaling they haven’t thought through these issues systematically. That’s a red flag for Risk.
How to Reframe Risk from Obstacle to Ally
Here’s the counterintuitive truth: Risk teams can become your strongest advocates if you approach them correctly.
Why? Because Risk professionals spend their careers dealing with vendors who don’t take their concerns seriously. When they meet a vendor who genuinely understands risk management and has built appropriate controls, they’re often impressed and even enthusiastic.
Here’s how to build that relationship:
1. Request a meeting with Risk early
Don’t wait for Risk to get involved late in the sales cycle. Proactively request a meeting after your initial business conversations. Frame it as: “We want to understand your risk management requirements so we can address them from the start.”
This signals you respect their function and want to work with them, not around them.
2. Speak their language
Learn basic risk terminology: operational resilience, business continuity, concentration risk, control environment, third-party risk management. Use it correctly. This demonstrates you understand their world.
Avoid hyperbolic marketing language. Risk teams are allergic to claims that sound too good to be true. Understated confidence beats aggressive selling.
3. Present risks honestly, with mitigations
Don’t pretend your solution is risk-free. Every technology solution creates some risk. Acknowledge it honestly, then explain your mitigation approach.
“Yes, this creates a dependency on our service. Here’s why we believe that risk is manageable: our redundancy architecture, our disaster recovery testing, our incident response capabilities, and the SLA commitments we’re willing to make.”
This approach builds credibility. Risk teams trust vendors who acknowledge risks more than vendors who deny them.
4. Demonstrate operational maturity
Show that you operate with discipline and controls:
- Regular disaster recovery testing
- Documented incident response processes
- Security monitoring and alerting
- Change management procedures
- Compliance framework
- Regular third-party audits
You don’t need to be perfect, but you need to demonstrate you’re serious about operating in a regulated environment.
5. Offer transparency and oversight mechanisms
Risk wants ongoing visibility into vendor performance and risk indicators. Offer it proactively:
- Regular risk reporting
- Incident notification commitments
- Access to audit reports
- Security review rights
- Business continuity testing participation
This makes Risk comfortable that they can monitor and manage the relationship over time.
6. Make them look good internally
Risk teams need to justify their decisions to senior management and auditors. Help them by providing:
- Clear risk assessment documentation
- Evidence of due diligence
- Comparison to alternative approaches
- Mitigation strategies
- Ongoing monitoring plans
When you make it easy for Risk to say yes, they’re more likely to advocate for your solution.
The Conversation That Changes Everything
Here’s a conversation framework that works with Risk teams:
You: “Before we go further, I want to make sure we understand your risk management requirements. What are the key risk concerns you’d have with a solution like ours?”
Risk: [Articulates concerns about operational resilience, vendor viability, data security, etc.]
You: “Those are all legitimate concerns. Let me walk through how we’ve designed our approach to address each of them. [Present detailed risk mitigation approaches]. What else would you need to see to be comfortable?”
Risk: [Articulates additional requirements or documentation needs]
You: “We can provide that. Some of it we have ready now, some will take a few weeks to prepare. Would it help if we scheduled a follow-up meeting once we have everything together, and you can assess whether it meets your requirements?”
This conversation demonstrates respect for Risk’s mandate, willingness to address their concerns thoroughly, and understanding that their approval is necessary. It turns a potential adversarial dynamic into a collaborative one.
When Risk Says No (And What to Do About It)
Sometimes Risk will identify deal-killing concerns that you genuinely can’t address. Maybe you don’t have sufficient financial backing. Maybe your technology architecture has fundamental resilience issues. Maybe you don’t have adequate security controls.
When this happens, don’t fight it or try to minimize the concerns. Risk isn’t being unreasonable—they’ve identified real issues that create unacceptable risk for the bank.
Your options are:
- Fix the underlying issue and come back when you’re ready
- Propose a limited pilot that reduces risk exposure while you build additional capabilities
- Acknowledge this isn’t the right time and maintain the relationship for future opportunities
What doesn’t work: pressuring your business champion to override Risk. This creates internal conflict, damages your relationship with both functions, and usually fails anyway because Risk has independent authority.
The Long Game with Risk Teams
Building credibility with Risk takes time, but it pays enormous dividends. Once Risk is comfortable with you, they often advocate for expanding the relationship because onboarding new vendors creates more risk than expanding proven ones.
This is why your first bank deal is hardest and subsequent ones get easier. Risk has seen your operational maturity, your incident response, your resilience under pressure. They trust you in ways they can’t trust vendors they haven’t worked with.
Invest in building strong relationships with Risk teams. Respond quickly to their information requests. Be transparent about incidents. Deliver on commitments. Over time, you’ll build a reputation as a vendor they’re comfortable with. That reputation becomes a competitive advantage that’s nearly impossible for competitors to replicate quickly.
The Reality Check
Look at your bank deals that stalled after Risk got involved. In most cases, the issue wasn’t that Risk was unreasonable—it’s that you hadn’t anticipated their concerns and weren’t prepared to address them.
The deals that move forward are the ones where vendors proactively engage Risk, thoroughly address their concerns, provide the documentation they need, and demonstrate operational maturity. The deals that stall are the ones where vendors treat Risk as an obstacle to route around rather than a legitimate gatekeeper to win over.
In the next post, we’ll tackle another common point of failure: POCs that succeed technically but never convert to production. You’ll learn why technical proof isn’t sufficient in banking and how to design proof-of-concept engagements that actually lead to contracts.