Addressing Software Development Challenges in Financial Services

If you run engineering in a bank, insurer, or payments business in the EU, the ground shifted on 17 January 2025. That is the day the Digital Operational Resilience Act (DORA) became legally applicable, and it converted a set of soft "compliance" aspirations into hard, software-level legal obligations with board-level accountability. The challenges in financial services software development have not changed in name, but they have changed in weight. This is a briefing on the three that now dominate delivery planning: regulatory resilience as a code property, governing an open-source supply chain you no longer control, and shipping fast without quietly trading away stability.

DevOps lifecycle diagram showing plan, build, test, release, deploy, operate and monitor stages feeding back into each other for regulated software delivery

Regulatory compliance is now an engineering requirement, not a legal afterthought

The old framing treated regulation as a gate the legal team owned and engineering passed through. DORA dismantles that handoff. The regulation covers almost every EU financial entity, including banks, insurers, payment and e-money institutions, investment firms, and crypto-asset service providers, and it mandates ICT risk management with explicit board accountability, third-party ICT provider oversight, major-incident reporting, and threat-led penetration testing (Mayer Brown, 2025). Read that list as a system requirements document, because that is what it is. "Oversight of third-party ICT providers" means you need a current, accurate inventory of every vendor and dependency in your critical path. "Major-incident reporting" on a tight timeline means your observability and on-call tooling have to produce a regulator-grade narrative quickly, not a postmortem written from memory a week later.

What used to be vague penalty language is now a number on the table. Under DORA, non-compliance can trigger penalties of up to 2% of total annual worldwide turnover, or EUR 10 million for individuals (SureCloud, 2025). That figure is the reason "we will harden it later" stops being a defensible position. The practical move is to make compliance a code property: codify controls as policy-as-code in the pipeline, treat your software bill of materials and vendor register as living artifacts that build tooling maintains, and wire incident detection to the reporting timeline rather than to a quarterly review. Resilience testing is not a one-off audit event; build it into the release cadence so the evidence the regulator wants is a byproduct of how you already ship.

Open source is now the platform, and governance is the hard part

The shift to open source in finance is no longer a trend to debate; it is the substrate everything runs on. Over 85% of banking, insurance, and financial-services organizations are increasing their open-source usage (FINOS 2024 State of Open Source in Financial Services). For an engineering director, the interesting finding in that survey is not the adoption rate but the governance gap. Firms with an Open Source Program Office or a visible open-source leader are far more likely to encourage both consumption (62% versus 29%) and contribution, while maintaining security policy and regulatory compliance remains a top reported challenge. Translation: the difference between safe and reckless open-source use is organizational, not technical. The teams that win have a named owner and a policy, not just a permissive license to pull packages.

The reason this matters more every year is the threat surface those dependencies represent. Developers were projected to download 6.6 trillion open-source packages in 2024, and Sonatype has identified 704,102 malicious open-source packages since 2019, a 156% year-over-year jump in malware (Sonatype 2024 State of the Software Supply Chain). The same dependencies that let a small team move fast are the same dependencies an attacker uses to reach your build system. In a regulated environment, where DORA already obliges you to oversee third-party ICT risk, your transitive dependency graph is third-party ICT risk. The controls that follow are unglamorous and non-negotiable: a generated SBOM on every build, dependency provenance and signature verification, automated vulnerability gating that fails the pipeline rather than filing a ticket, and a curated internal registry so engineers are not pulling unvetted artifacts straight from public mirrors. This is the concrete content behind the SecDevOps label, and it is where the security investment actually pays off.

Delivering business value fast is a platform problem, not a tooling problem

Every financial institution wants to ship faster, and most reach for new tools to get there. The 2024 evidence argues that tooling alone is the wrong lever, and in one case an actively counterproductive one. The 2024 DORA Accelerate State of DevOps report found that a 25% increase in AI adoption correlates with an estimated 1.5% decrease in software delivery throughput and reduced delivery stability, even as AI lifts individual developer productivity (2024 Accelerate State of DevOps Report, via InfoQ). That is the central tension this article's predecessor gestured at without quantifying: faster individuals do not equal a faster system. More code generated more quickly, fed into a delivery pipeline that cannot review, test, and release it safely, increases batch size and queue time rather than reducing it.

The same report notes that only around 19% of teams reach elite delivery performance, deploying on demand with lead times under a day. What separates them is rarely a single tool; it is platform engineering and developer self-service that remove friction from the path to production. For a regulated finance team, the synthesis is clean: invest in the platform that lets engineers ship a compliant, tested, observable change without a series of manual handoffs. Build the compliance controls, the SBOM generation, the security gates, and the deployment automation into a paved road so that doing the right thing is also the fast thing. That is how speed and stability stop being a trade-off. You do not balance them by slowing down; you balance them by making the safe path the default path.

Where this leaves your roadmap

The three challenges converge on a single discipline: treat regulatory resilience, supply-chain security, and delivery speed as properties of one platform rather than three separate workstreams owned by three separate teams. DORA gives you the requirements, the open-source data gives you the threat model, and the DevOps research gives you the delivery model. At Expeditious Software, our DevOps services and freelance DevOps expertise focus on exactly this integration, embedding security and compliance into the pipeline so that regulated financial software is shipped quickly because it is built to be auditable, not in spite of it.