Five vendor proposals land on your desk. Day rates range from $45 an hour to $180. All five slide decks show the same case study categories. Four promise "dedicated squads." Three mention DORA without being asked what it is. The decision you are about to make is not really a vendor selection. It is a bet on which supplier understands that banking software development carries different failure modes than the rest of the software market.
Most banking engineering programmes fail during vendor selection, not during delivery. The procurement document says "build a new payments ledger" and the shortlist is scored on day rate, team size, and case-study logos. Delivery starts. Six months in, a compliance audit surfaces gaps the vendor cannot remediate because their engineers have never read a UK PRA supervisory statement or an EU DORA article. Scope renegotiation starts. The bill grows. The launch slips.
This is the core mismatch in banking software vendor selection: buyers procure a staffing contract and expect partner-level accountability. The two are not the same product. This post is a checklist, nine criteria weighted by how they protect you from the failure modes that actually show up in regulated financial software programmes. Apply it when you are scoring proposals, not when you are writing the statement of work.
Why Most Banking Software Development Engagements Miss
The market for banking software development services is crowded with engineering agencies that treat banking as just another vertical. The agency website lists banking alongside healthcare, retail, and logistics. The engineer you are assigned has delivered a React dashboard for a logistics client and a Kubernetes cluster for an ecommerce client. The banking knowledge comes from the agency's account manager, not the senior engineer on the keyboard.
This works for a long time. It fails at three specific moments. The first is an unplanned audit or supervisory visit, where the regulator asks your vendor's engineering lead to explain how transaction logs survive their retention policy and the answer is a shrug. The second is a compliance change, such as the January 2025 entry into force of DORA in the EU or PCI DSS 4.0.1 enforcement, where your vendor cannot tell you which of their architecture decisions are now non-compliant. The third is a production incident where the vendor's observability handover is a Confluence page from 2023 and the on-call engineer at 3am has never touched your system.
Those three failure modes are not random. They are predictable, and they correlate with specific signals in the proposal stage. The checklist below is organised around detecting those signals before you sign.
The Nine Criteria That Separate Partners From Body Shops
Treat this as a scoring framework, not a questionnaire. Each criterion maps to a category of delivery risk. Weight them for your programme: a greenfield retail challenger build emphasises compliance fluency and observability; a core migration emphasises engineering seniority mix and exit-clause terms; a payments platform emphasises security audit readiness and IP portability.
1. Delivery Accountability Structure
Ask: who is contractually accountable if the team misses a milestone, and what does "accountable" actually mean in your master services agreement?
A body-shop contract assigns accountability to the buyer. The vendor supplies engineers; the buyer manages them. If a release slips, the buyer's engineering manager absorbed the delay by not managing tightly enough. A partner contract assigns joint accountability. The vendor's delivery lead co-owns the milestone with the buyer's technical lead, and missed milestones trigger defined remediation (credit, additional resource, escalation to an executive steering committee).
Red flag in proposals: the word "dedicated" without a named delivery lead, a defined escalation path, or a service-credit clause. "Dedicated squad" with no joint-accountability language is staffing dressed up.
2. Compliance Fluency
Ask the senior engineer (not the account manager) to explain how they would approach DORA third-party ICT risk reporting, PCI DSS 4.0.1 secure software lifecycle requirements, and the split between PSD2 strong customer authentication and the UK PSR's equivalent regime.
You are not testing for a perfect answer. You are testing whether the engineer has read the regulations and translated them into architectural decisions before. A fluent engineer names the specific articles (DORA Article 28 for ICT third-party risk, PCI DSS 4.0.1 Requirement 6 for secure software, etc.) and maps them to concrete implementation patterns (immutable audit logs, SBOM generation in CI, runtime compliance-as-code gates). A non-fluent engineer cites the acronym and stops there.
This criterion is the most predictive single signal in the checklist. A vendor whose senior engineers cannot hold a fifteen-minute conversation on DORA implementation will not catch the Article 28 gap in your architecture during delivery.
3. Engineering Seniority Mix
Ask for the proposed team composition at the level of individual named engineers, with years of financial services delivery and links to prior work (case-study pages, public conference talks, published architecture decision records, open-source contributions to finance-adjacent libraries).
The metric is not "average years of experience," which is easily gamed by rolling one 20-year principal into a team of eight juniors. The metric is the proportion of engineers with at least three years of direct regulated-financial-software delivery. A partner typically fields 50 percent or more at that threshold. A body shop typically fields under 20 percent and makes up for it with the aforementioned principal appearing on status calls for fifteen minutes a week.
Validation step: request CVs or LinkedIn profiles for the named engineers. Check whether their recent work history matches financial services. Check whether they have the specific compliance or payments experience your programme needs.
4. Regulatory Reference Work
Ask for two reference clients where the vendor's engineering team worked directly on a system that was subject to a named regulation, and whether the vendor's engineers interacted with the regulator or the internal compliance team during that programme.
The distinction matters. "We built a payments app for a neobank" and "We built a payments app for a neobank and participated in their PRA supervisory engagement on operational resilience" are different reference points. The first tells you they can ship. The second tells you they can ship under scrutiny.
If a vendor cannot produce two regulator-adjacent references, they may still be a fine staffing supplier. They are not a partner for a regulated programme.
5. Security Audit Readiness
Ask for current SOC 2 Type II or ISO 27001 certification status, plus the date of the last third-party penetration test against their delivery environments and whether the test report is available under NDA.
"We take security seriously" without a current certification and an auditable pen-test report is a marketing sentence, not a control. Your vendor's delivery environment becomes part of your attack surface on day one. If their laptop fleet, CI/CD pipelines, and code repositories are not audited annually, you have inherited their blind spots.
Additional check: ask for their incident-response runbook and how long it took them to remediate the last security incident they disclosed to a client. A vendor without a runbook, or with a runbook they will not share, cannot carry your risk during a live incident.
6. Observability Handover
Ask what you will receive at the end of the engagement (or at quarterly checkpoints) in terms of runbooks, architecture decision records, dependency maps, monitoring dashboards, and on-call escalation procedures.
The failure pattern here is specific. Delivery feels fine. The vendor ships. Three months after the engagement ends, your internal team hits a production issue at 2am, opens the Confluence space the vendor left behind, and finds a half-complete runbook that references services the vendor renamed six weeks before go-live. You are now operating blind.
A partner treats the observability artefact as a deliverable with its own acceptance criteria. A body shop treats it as something to write on the last Friday of the contract. Score this criterion by asking to see a sample handover package from a prior client (redacted for confidentiality). If they cannot produce one, they have never treated it as a deliverable.
7. IP and Portability Terms
Ask who owns the code, who owns the architecture, who owns the configurations, and under what conditions you can take all of it to another vendor or bring it in-house.
The default position in many body-shop contracts is that the vendor retains IP on reusable components and grants the buyer a licence. This sounds fine until you try to leave. At that point the "reusable components" turn out to include the authentication middleware, the compliance logging framework, and the deployment pipeline, and the vendor's licence does not survive contract termination.
Required contract terms for a partner engagement: full assignment of IP to the buyer on payment, escrow of build configurations and runbooks, no restrictive licences on middleware the buyer's system depends on at runtime. If these are non-negotiable for the vendor, they are structurally a body shop regardless of what their sales deck says.
8. Exit Clause Terms
Ask what a clean exit looks like, what the vendor's obligations are during the transition window, and what is specifically excluded from transition support.
Banks almost never exit vendors cleanly. Contracts are renewed because the cost of exit exceeds the cost of another year of frustration. A partner engagement bakes exit into the contract from day one: a defined transition window (commonly 90 days), a named knowledge-transfer plan, continued access to key engineers for a tail period, and a clause prohibiting critical-path dependencies on vendor-proprietary tooling without buyer consent.
Body-shop contracts tend to omit these. The assumption is that you will not leave. The partner model assumes you could, and makes the exit affordable so that your ongoing renewal is a genuine choice rather than a lock-in.
9. On-Shore or Nearshore Split
Ask where the engineers sit, where the data sits, and how the two overlap with your regulatory jurisdiction.
Data residency constraints are not new, but the specifics tightened under DORA (for EU financial entities), UK PRA expectations on outsourcing, and state-level regulations in the US. A nearshore or offshore team is not a disqualifier. An opaque nearshore or offshore arrangement is. You need to know, on day one, which engineers hold which data access permissions in which jurisdictions, and whether the arrangement satisfies your compliance team's residency matrix.
The checklist question is concrete: can the vendor produce a data-access map showing which engineer roles see which data categories in which countries, and is that map part of the proposal or an afterthought? A partner produces the map in the proposal. A body shop produces it after you ask three times.
What Good Looks Like in Practice
A vendor proposal that scores well on the checklist is rarely the cheapest, but the cost differential is smaller than most procurement teams expect. The typical partner day rate sits 20 to 40 percent above a body shop for comparable seniority. The total programme cost is often lower because rework, compliance remediation, and exit friction are lower.
When Scrums.com works with banks, the shortest path to evaluating fit is to skip the 20-slide introduction and run a ninety-minute technical discovery session with the named engineering lead against a specific problem in the buyer's environment. If the lead cannot discuss the problem with regulatory and architectural fluency in that session, the rest of the relationship will not recover that gap.
For decision-stage context on the architectural patterns that sit downstream of the vendor selection, see our breakdown of modern banking architecture for scale and compliance. For the specific case of replacing legacy core platforms, our guide to modernising legacy vendors in banking covers the adjacent question of how to sequence migrations once the partner is in place.
Common Procurement Mistakes to Avoid
Three patterns repeat across failed banking software programmes.
Over-indexing on day rate. A 40 percent day-rate differential disappears into rework in the first compliance audit gap. Compare total programme cost modelled over three years, not headline rate.
Scoring case-study logos. A logo on a case-study page does not tell you which engineer worked on it, what they did, or whether that engineer is on your team. Push for named engineer attribution on any case study cited during selection.
Skipping the compliance-fluency interview. A senior engineer from the vendor should be on a call with your compliance or risk lead before contract signature. If the vendor resists this, they are resisting because they know it will not go well.
Applying the Checklist
Score each of the nine criteria on a 1 to 5 scale against each proposal. Weight the criteria for your specific programme (a compliance-heavy programme weights criteria 2, 4, and 5 higher; a core migration weights 3, 7, and 8 higher). A vendor scoring below 3 on criterion 2 (compliance fluency) should be excluded regardless of cumulative score. Criteria 7 and 8 (IP and exit) are pass-fail; any failure here is a structural mismatch with a partner engagement.
The point of the scorecard is to surface the body-shop-versus-partner distinction early, in the language of procurement, rather than during delivery when the cost of discovery is already sunk. Used well, the checklist shortens the selection process, improves vendor quality, and reduces renegotiation during delivery.
If you are drafting a shortlist now, talk to the Scrums.com team about how we would approach your specific programme. We respond within 48 hours with a named engineering lead on the first call.
Frequently Asked Questions
What is banking software development?
Banking software development is the design, build, and operation of software systems that serve regulated financial institutions, including core banking platforms, payments systems, digital banking front-ends, fraud and AML tooling, and internal risk and compliance platforms. It differs from general software development because every architectural decision is constrained by regulations such as DORA (EU), PCI DSS (global cards), PSD2 and the UK PSR (payment services), and jurisdiction-specific banking laws. Technical fluency alone is not sufficient; regulatory fluency is a required competence.
What is the difference between a banking software development vendor and a partner?
A vendor supplies engineering capacity under a staffing contract; the buyer manages the team, owns delivery risk, and absorbs the cost of any compliance or architectural gaps. A partner enters into a joint-accountability contract where delivery risk is shared, the vendor's delivery lead co-owns milestones with the buyer, and exit terms are defined from day one. Both models can work, but buyers often procure a vendor while expecting partner-level accountability, which is the root cause of most failed programmes.
How much should banking software development cost?
Day rates for senior engineers on banking programmes typically range from $90 to $200 per hour depending on region, seniority, and specialism (payments, core banking, fraud). The headline rate matters less than the total-programme cost modelled over three years, which includes rework, compliance remediation, handover quality, and exit friction. A partner engagement often carries a higher day rate but a lower total-programme cost because the second-order costs compress.
What regulations does a banking software development vendor need to understand?
For EU and UK-facing programmes, the baseline is DORA (Digital Operational Resilience Act, in force since January 2025), PSD2 and the UK PSR's equivalent, GDPR, and PCI DSS 4.0.1 where cards are in scope. US-facing programmes add GLBA, NYDFS Part 500, state-level requirements such as the Texas banking code, and SOX controls where the bank is publicly listed. Vendors should demonstrate that their senior engineers have read the specific regulatory text, not just the compliance summary.
What is the single strongest signal of vendor quality?
Compliance fluency at the engineer level. Ask the senior engineer assigned to your programme to discuss how they would implement a specific regulatory article, such as DORA Article 28 on third-party ICT risk reporting. A fluent engineer will map the article to architectural decisions (immutable logs, ICT register integration, SBOM artefacts, runtime policy gates). A non-fluent engineer will paraphrase the article or defer to the account manager. Fluency at the engineer level is the most predictive single signal because every other failure mode in a regulated programme traces back to someone not understanding the rules during delivery.
