Every engineering leader in financial services is now managing the same contradiction. The business wants the deployment cadence of a fintech challenger. The regulator wants documented, reproducible, defensible control over every change that touches a payment, a ledger, or customer data. For most of the last decade those two pressures were treated as a trade-off you negotiated quarter by quarter. Since DORA became mandatory across the EU, that negotiation is over: you are expected to demonstrate both velocity and continuous operational resilience, and to prove it on demand with evidence. The teams handling this well are not the ones who picked a side. They are the ones who moved their controls into the pipeline.
This piece is about the four pressures that actually constrain the SDLC in a regulated, high-scale finance environment right now, what the data says about each, and what disciplined teams do differently. None of it is theoretical. All of it shows up in the change-failure rate, the audit findings, and the attrition numbers.
AI is buying you throughput and selling you instability
The headline from the 2025 DORA / Accelerate State of DevOps report is genuinely good news, and it is a trap if you stop reading there. AI's relationship with software delivery throughput reversed from negative in 2024 to positive in 2025, with 90% of respondents now using AI in their job at a median of two hours a day. Teams ship more. But instability is the one major delivery metric AI still makes worse: AI adoption correlates with more change failures, higher rework, and longer time to recover from failed deployments. DORA's framing is the part to internalize - AI is an amplifier of an organization's existing strengths and weaknesses, not a fix for them.
For a generic SaaS team, a higher change-failure rate is a cost. For a bank operating under SOX segregation-of-duties requirements and DORA resilience obligations, shipping faster while change failures and rework climb is exactly the failure mode auditors and regulators penalize. The 2026 State of Code survey explains the mechanism: the work has shifted from code creation to verification and debugging, and 96% of developers do not fully trust the functional accuracy of AI-generated code, with only 4% completely agreeing that it is functionally correct. In a sector where verification is mandatory rather than optional, an unmitigated AI rollout doesn't relieve toil - it relocates it to the most expensive, most regulated stage of your pipeline.
Compliance has become a continuous, evidence-heavy tax on delivery
DORA changed the unit of compliance from the annual audit to the running system. Since it became mandatory on 17 January 2025, EU financial entities must prove operational resilience continuously: structured ICT-incident classification with standardized regulatory reporting, threat-led penetration testing and scenario drills with documented remediation, continuous third-party ICT risk monitoring with exit strategies, and independent audit evidence. This stacks on top of PCI-DSS, SOX, and GDPR rather than replacing any of them - and PCI-DSS, SOX and GDPR each impose their own constraints on the SDLC, from encryption and continuous auditing of payment data to documented approvals and segregation of duties for every code change.
The penalties make this a board-level number, not an engineering footnote. DORA non-compliance carries fines up to 2% of annual worldwide turnover or EUR 1 million for institutions, and up to EUR 5 million for critical ICT providers. Hogan Lovells, reviewing the landscape six months in, found the compliance journey far from complete, with entities still reworking governance, incident-response and business-continuity arrangements. The predictable result is governance becoming the dominant velocity constraint. One bank executive told Deloitte that elevated compliance oversight "definitely impacted our team's overall velocity." This is why mature teams are moving to governance as code: automated policy gates and audit-ready evidence generated by the pipeline, instead of spreadsheets and approval tickets reconstructed under deadline.
Legacy plus change-control bureaucracy is where your capacity goes
The reason this is hard is structural, not cultural. Mainframes still process roughly 68% of global production IT workloads, and most banking IT budgets go to legacy maintenance rather than innovation - while fintech competitors release weekly. You cannot rip the core out, so the constraint is permanent and must be engineered around.
Underneath that, technical debt is a continuous drain on the exact engineers you most want building new capability. Deloitte's numbers are blunt: 33% of developer time goes to technical-debt maintenance, and 78% of engineers say legacy systems negatively affect morale - which is an attrition driver, not just a sentiment metric. Layer manual handoffs through tickets and approval boards on top, and a large fraction of your capacity is consumed before anyone writes a feature. The consensus remedy is platform engineering - paved roads, internal developer portals, embedded compliance, and automated quality gates that produce smaller, auditable changes which are easier to test, roll back, and prove to an auditor. The direction of travel is clear enough that Gartner projects 80% of large software-engineering organizations will have platform-engineering teams by 2026, up from 45% in 2022. The payoff is concrete: Software Mind cites Capital One cutting development environment build time from three months to minutes.
The software supply chain is now an audit obligation, not a scan
Open-source components make up 80-90% of modern applications and sit underneath nearly every financial system, and the threat against them is escalating sharply. Sonatype's 2026 report recorded more than 1.2 million malicious packages blocked. Triage is harder than it looks on a dashboard: 65% of new vulnerabilities lack severity scores, so you cannot simply gate on CVSS. And AI introduces a new vector directly into the dependency graph - roughly 27% of AI dependency suggestions are invalid or risky hallucinations.
Regulation has converged to meet this. SBOMs, secure-by-design attestation under the EU Cyber Resilience Act and US NIST SSDF/CISA guidance, and demonstrable oversight of third-party software risk now appear directly in procurement cycles and audit practice - reinforced by DORA's ICT third-party mandates. CRA penalties reach 2% of global revenue, and software-assurance regulation is converging globally rather than staying region-specific. For a finance engineering director, the implication is specific: SBOM generation, dependency provenance, and continuous vulnerability gating have to be standing, audit-ready parts of the pipeline, not a periodic scan someone runs before a release.
What good looks like
The teams absorbing all four pressures without grinding to a halt share a recognizable shape:
- Controls live in CI/CD, not in tickets. Segregation of duties, change approval, and policy checks are enforced and logged by the pipeline, so the audit artifact is a byproduct of shipping rather than a separate reconstruction effort.
- AI output is gated by verification, not trust. Given that 96% of developers don't fully trust AI-generated code, the change-failure rate and rework metrics are watched directly, and AI is rolled into teams that already have strong testing - because it amplifies what's there.
- Changes are small, reversible, and provable. Smaller auditable deployments with real rollback are both the resilience story DORA wants and the velocity story the business wants.
- Supply-chain evidence is continuous. SBOMs and provenance are generated every build, and gating accounts for the 65% of vulnerabilities with no severity score and the risk of hallucinated dependencies.
The discipline is the strategy
None of these four pressures is solvable by a tool purchase or a one-time program. They are properties of operating regulated, high-scale software, and they compound: AI instability lands hardest on legacy-heavy estates, compliance load is heaviest where change control is most manual, and supply-chain risk is widest where provenance is weakest. The common thread in every team that handles them is the same - a disciplined SDLC where resilience and auditability are engineered into the delivery platform rather than bolted on at review time. That is unglamorous, and it is the work. The institutions that treat platform engineering and governance-as-code as core delivery infrastructure are the ones turning DORA from a tax into a baseline they already meet.
Sources
- DORA 2025: Measuring Software Delivery After AI (RedMonk analysis of Google Cloud / DORA 2025 State of DevOps Report)
- What the 2026 State of the Software Supply Chain Report Reveals About Regulation (Sonatype)
- What Is The Digital Operational Resilience Act (DORA)? 2025 Guide (Octopus Deploy)
- How should banks respond to the current disruption in software engineering? (Deloitte Insights)
- DevOps in Banking: Benefits, Challenges & Best Practices (Software Mind)
- The EU Digital Operational Resilience Act (DORA): top 7 challenges for IT vendors (Hogan Lovells)
- 2026 State of Code Developer Survey: navigating the AI verification bottleneck (Sonar)