A few months back, a payments startup reached out to us after their previous vendor had delivered a “working” app that failed PCI-DSS compliance checks three separate times. The founder had signed a contract based on a slick pitch deck and a few portfolio screenshots. Six months and a lot of money later, they were back to square one.
This happens more often in BFSI and fintech than anyone likes to admit. You’re not just buying code — you’re trusting a team with regulatory compliance, customer financial data, and uptime guarantees that can’t fail at 2 AM on settlement day. So the vetting process needs to go deeper than “do they have good reviews.”
Here’s what we’d actually tell you to check before signing anything — based on what we’ve seen go right and wrong across fintech and BFSI engagements.
1. Ask for domain-specific case studies, not just a portfolio
Any agency can show you a banking app screenshot. Ask them to walk you through a project where they handled something specific to your problem — reconciliation logic, KYC workflows, loan origination systems, or real-time fraud scoring. If they can’t explain the architecture decisions they made and why, the project was probably led by someone else on their team who’s no longer there, or they outsourced it.
For one of our NBFC clients building a loan management system, the deciding factor wasn’t our pitch — it was that we could explain exactly how we’d handle CIBIL API rate limits and fallback logic during peak disbursement hours. That level of specificity tells you whether a team has actually shipped in this space or is learning on your dime.
2. Dig into their compliance and security process, not just certifications
ISO 27001 and SOC 2 badges on a website mean very little if you don’t ask how they’re operationalized. Ask pointed questions:
- How do they handle data encryption at rest and in transit for customer financial records?
- What’s their process for code reviews involving PII or payment data?
- Do developers have access to production databases, and if so, under what controls?
- Have they worked with RBI’s data localization requirements or similar regulations in your jurisdiction?
A vendor who’s actually dealt with BFSI compliance will have specific, slightly boring answers — audit logs, access control matrices, environment segregation. If the answer is vague reassurance (“don’t worry, we take security seriously”), that’s a red flag.
3. Talk to their past clients — and ask the uncomfortable questions
Everyone gives you two or three glowing references. Ask instead: “Can I speak to a client whose project ran into delays or scope changes?” How a company handled a project that went sideways tells you far more than one that went perfectly.
When you do get a reference call, ask things like: Did they flag risks proactively or did problems surface late? Did the team composition stay stable, or did developers rotate mid-project? For a fintech client of ours building a UPI-based collections tool, the reference check actually revealed our previous client had changed scope twice — and the client wanted to know how we’d responded, not whether we were perfect.
4. Understand who you’re actually working with day to day
A common trap: you meet a sharp solutions architect and a confident account manager during sales calls, then get handed off to a junior team once the contract is signed. Ask explicitly:
- Who will be the lead developer or tech architect on my project, by name?
- Will this person stay through the engagement, or rotate out?
- What’s the actual team structure — onshore, offshore, hybrid?
Get this in writing in the contract or SOW if it matters to you. It should.
5. Review how they handle IP ownership and code escrow
This one gets overlooked constantly. Who owns the source code once the project ends? Can you take the codebase and move to another team without the original vendor holding anything hostage — access keys, deployment pipelines, documentation? For BFSI clients especially, we always recommend putting code escrow or full repository handover clauses directly into the MSA, not leaving it as an assumption.
6. Test their estimation and communication style before you commit
Give them a real, moderately complex problem from your actual roadmap during the proposal stage — not a generic RFP question. See how they break it down. A team that pads every estimate with buffer and vague timelines is different from one that says, “this part is straightforward, but this integration with your core banking system is the real risk, and here’s how we’d de-risk it first.”
That kind of honesty upfront, even when it’s less flattering, is usually a better predictor of how they’ll behave six months into a live project than any pitch deck.
Final word
Evaluating a dev partner for BFSI or fintech work isn’t about finding the cheapest quote or the most polished sales deck. It’s about finding a team that’s handled the specific headaches your industry throws up — compliance audits, legacy core banking integrations, data residency rules — and can talk about them without flinching. Ask harder questions before you sign. It’s a lot cheaper than finding out the hard way after.
