Two numbers should decide how your next vendor conversation goes. The Verizon 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled to 30% in a single year. The IBM Cost of a Data Breach Report 2025 puts the average financial-sector incident at $5.56 million, roughly $1.12 million above the cross-industry average.
Read them together, and the conclusion gets uncomfortable. When a bank signs a software development partner, it isn't buying engineering capacity. It's extending its regulatory perimeter to a company it doesn't control. The build gets outsourced. The liability never does.
Most vendor-selection guides still open with team size and hourly rates. This one is about the questions that survive an audit. Here's how to evaluate a software development partner when the code being written will touch a ledger, a regulator, and somebody's mortgage.
Why DORA Rewrote the Software Development Partner Decision in 2026
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has been fully applicable since 17 January 2025, and it changed the legal status of the firm building your loan origination system. Under Articles 28 to 30, that firm is an ICT third-party service provider. Your software development partner enters your Register of Information. Its criticality gets classified. And you, not the vendor, stay fully responsible for the resilience of the function it delivers.
Supervisors have already picked their battleground. The EBA, ESMA and EIOPA have consistently flagged Articles 28 to 30 as the primary source of compliance gaps: incomplete registers, missing criticality classifications, and Article 30 contract clauses that don't meet the mandatory standard.
There's a second layer landing on top. Credit scoring and insurance pricing models fall into the EU AI Act's high-risk category. The obligations were written to apply from 2 August 2026, though the Digital Omnibus agreement reached in May 2026 provisionally pushes Annex III high-risk systems to December 2027, pending publication in the Official Journal. Plan against the earlier date anyway. A delay you counted on and didn't get is a product you can't ship.
US institutions face a parallel stack: OCC and FDIC third-party risk guidance, GLBA, the FTC Safeguards Rule, and NYDFS 23 NYCRR 500. Different acronyms, identical logic.
Stop Opening Vendor Calls With the Tech Stack Question
React or Vue. AWS or Azure. Microservices or a monolith. These questions fill the first call with a prospective software development partner, and they're close to worthless as a filter, because every serious firm has a rehearsed answer ready.
Financial software fails differently from other software. A bug in a consumer app irritates somebody. A bug in a payment ledger double-posts a transaction, corrupts reconciliation, and resurfaces in an audit four months later.
So ask the questions only a team that has shipped into production can answer. How do you enforce idempotency when a payment gateway times out but the debit already cleared? What does your reconciliation flow do with a partial batch failure at 2 a.m.? How did you handle data residency when a client's processing had to stay inside the EU? What happened the last time an integration partner changed an API contract mid-sprint?
The answers separate structural domain knowledge from a case study somebody memorised. A software development partner that has genuinely built financial systems answers with specifics and a war story. One that hasn't answers with a methodology slide.
The Eight-Dimension Scorecard for Rating a Software Development Partner for Finance Companies
Gut feel doesn't survive a procurement committee, and it certainly doesn't survive a supervisor asking how you selected a critical vendor. Score your software development partner instead. A weighted model that holds up in financial services:
- Technical capability: 25%
- Security and compliance: 20%
- Process and delivery maturity: 15%
- Team structure and continuity: 15%
- Cost structure: 10%
- IP ownership and contract terms: 7%
- Communication and governance: 5%
- Capacity to scale the team: 3%
Rate each dimension 0 to 10, multiply by its weight, and you land on a defensible composite out of 100. The arithmetic isn't the point. The point is that every score has to be justified with an artefact, and those artefacts become your pre-contract due diligence file.
Compliance Certifications and Security Evidence to Demand
Ask any software development partner for ISO 27001:2022 with the scope covering software delivery, not just corporate operations. SOC 2 Type II, scoped to how your data is actually handled. PCI DSS if cards go anywhere near the build. A third-party penetration test from within the last twelve months, not a summary of one from 2023.
Then make the request that quietly exposes maturity: the complete sub-processor list, with geography and certification status for each entry. Mature vendors produce it. The rest start negotiating.
Under DORA Article 28, this stops being optional for providers supporting critical or important functions. Firms must verify security standards with objective evidence, and ISO 27001 and SOC 2 Type II are precisely the artefacts a supervisor expects to find in the file.
Domain Proof
Logos prove somebody signed a contract. They prove nothing about what got delivered. Ask your prospective software development partner for a case study with the stack, the team size, the timeline, and a measurable outcome. Then ask what went wrong on it. Every real project has an answer to that question, and no invented one does.
This is where a generalist engineering vendor and a specialist financial software development services separate. One staffs your build with whoever is free on the bench. The other brings architects who already know why a double-entry ledger is not two rows in a table.
Team Structure, Named Architects, and Senior Continuity
The senior team in the pitch is not always the team in month nine. Ask for named architects and leads, written into the statement of work. Ask for median client tenure. A firm with several relationships past the five-year mark has proven its retention loop; a firm whose longest engagement is eighteen months is still proving the model.
Then ask where QA and security engineers actually sit. Embedded in design reviews, or bolted on after the code is written?
IP Ownership, Source-Code Escrow, and Exit Terms
Get IP assignment on payment in writing, not βon completionβ with completion left undefined. Ask for source-code escrow. And treat the exit clause as a first-class requirement rather than boilerplate: DORA Article 30 requires exit strategies with a mandatory transition period, during which the provider keeps the service running while you migrate elsewhere or bring it in-house.
A vendor who pushes back on that clause has told you everything you needed to learn.
Screen a Software Development Partner on Delivery Metrics, Not Sales Decks
Four numbers cut through a pitch deck faster than any reference call:
- Deployment frequency: how often do they actually ship to production?
- Lead time for changes: commit to live, measured in hours or weeks?
- Change failure rate: what share of deployments need a hotfix?
- Mean time to recovery: production broke on a Friday night. Then what?
A software development partner who can't answer those four with real data from real engagements is not production-ready for a regulated build. Ask for the raw numbers, not the averages they wish were true.
Pair the metrics with engineering hygiene checks: documented test coverage thresholds, SAST and DAST running in the pipeline, dependency and secrets scanning, and architectural decision records. The ADRs are the tell. A team that writes down why it chose an approach is a team that can explain itself to your auditor three years from now.
The Article 30 Contract Clauses a Regulated Build Actually Needs
For services supporting critical or important functions, DORA Article 30 sets the mandatory floor. The contract with your software development partner needs, at minimum:
- A complete description of the services, stating whether subcontracting is permitted and under what conditions
- The regions and countries where services are delivered and where data is processed, stored, and backed up
- Service levels with quantitative targets, not adjectives
- Unrestricted rights of access, inspection, and audit, for you and for your competent authority
- Incident assistance obligations, at no extra cost or at a cost agreed up front
- Full cooperation with competent authorities and resolution authorities
- Termination rights with defined minimum notice periods
- An exit strategy with a mandatory transition period
Contracts signed before 17 January 2025 had to be renegotiated to carry these clauses. The regulation writes in no grace period.
A software development partner who can support Article 30 clauses, feed your Register of Information, and help you plan an exit is taking risk off your balance sheet. A cheaper one who can't is quietly moving that risk onto it.
Conclusion
The right software development partner in 2026 isn't the one with the sharpest deck or the lowest hourly rate. It's the one whose evidence survives contact with your auditor: certifications scoped to delivery, delivery metrics they'll show you unpolished, domain answers with scar tissue in them, and contract terms written on the assumption the relationship could end badly.
Compliance fluency is the differentiator now, not cost. Institutions that treat financial IT services and solutions procurement as a risk-management discipline rather than a purchasing exercise will ship faster through 2026, simply because they'll spend less of the year rebuilding what a cheap vendor got wrong.
Run the eight-dimension scorecard against your current shortlist this week. If a vendor can't produce a sub-processor list and four delivery metrics within five business days, you've already learned more than any reference call was going to tell you.
Top comments (11)
The contrast between structural domain knowledge and a memorised case study is spot on. You can hear the difference in one call.
Asking for ADRs as an engineering maturity signal is a sharp tip. A team that documents its decisions can explain itself to an auditor.
Great breakdown of DORA Articles 28β30. Most articles mention DORA in passing β this one actually explains what changes in the contract.
Appreciate the honesty on the EU AI Act timeline; "plan against the earlier date anyway" is the right call. Regulatory delays are not a strategy.
The idempotency question for payment gateway timeouts is such a good filter. Any team that's actually shipped a ledger will have a war story ready.
Nice touch requiring an artefact behind every scorecard rating. That's what turns gut feel into a defensible due diligence file.
This should be required reading for any bank CTO running an RFP this year. Clear, practical, and grounded in actual regulation.
The sub-processor list test is underrated. You learn more from how fast a vendor produces it than from anything in the pitch deck.
Good insights on why building an AI-ready data foundation is critical for modern healthcare applications.
Loved the point about asking vendors what went wrong on a project. Real builds always have an answer; polished case studies never do.