Software Licensing in Financial Services: Compliance, Audit Risk, and Cost Control

The Dual Compliance Problem in Financial Services

Financial services organisations face a software licensing compliance challenge that has two distinct and compounding dimensions. The first is standard vendor licence compliance: ensuring that software deployments stay within the boundaries set by Oracle, Microsoft, IBM, SAP, and the other enterprise vendors whose platforms underpin banking, insurance, and asset management operations. The second is regulatory compliance: meeting the requirements of DORA, FCA, PRA, and other frameworks that mandate rigorous governance of third-party technology relationships — including the software these firms licence.

When these two dimensions collide — when a firm is simultaneously out of compliance with a vendor licence agreement and subject to regulatory scrutiny of its third-party IT governance — the consequences are severe. A vendor audit finding that would be a financial inconvenience in a less regulated industry can become a regulatory enforcement event in financial services, where evidence of poor third-party IT governance is material to supervisory assessments of operational resilience.

The good news is that the disciplines required to manage both dimensions are largely the same. A robust software asset management programme, strong vendor contract intelligence, and a disciplined renewal process address vendor compliance risk and contribute directly to meeting DORA's ICT third-party risk management requirements simultaneously.

DORA and Software Licensing: What Financial Firms Must Understand

The Digital Operational Resilience Act (DORA) became applicable across the EU from January 2025, imposing mandatory ICT risk management, incident reporting, and third-party oversight requirements on banks, insurers, investment firms, and other regulated financial entities. Even organisations headquartered outside the EU are within scope if they provide services to EU-regulated financial entities or use EU-regulated third-party ICT providers.

DORA's third-party ICT risk requirements have direct implications for software licensing governance. Article 28 requires financial entities to maintain a register of all ICT third-party service providers — including software vendors providing enterprise applications. The register must capture information on the service provided, the criticality of the service to the entity's operations, and the contractual terms governing the relationship. A financial services firm that cannot produce a complete, current record of its enterprise software contracts and the terms governing their use is not merely exposed to vendor audit risk — it is in breach of a regulatory requirement.

DORA also requires financial entities to ensure that contracts with ICT third parties include specific provisions: termination rights, data return rights, audit rights, and service continuity commitments. Software licence agreements — particularly legacy on-premises agreements negotiated before DORA was drafted — rarely include all of these provisions. Financial services firms need to audit their major software contracts against the DORA contractual requirements and prioritise remediation at the next renewal event for any agreement that falls short.

FCA and PRA Expectations

In the UK, the FCA's Operational Resilience framework (PS21/3) and the PRA's equivalent requirements set operational resilience expectations that, like DORA, have direct implications for software licensing governance. Firms must identify their important business services, map the IT assets that support them, and demonstrate that they can maintain those services within defined impact tolerances even in disruption scenarios. Software licence compliance is relevant here: a firm whose critical trading or payments infrastructure runs on software that is technically out of licence — for example, because a virtualisation deployment has created processor count discrepancies — is not able to demonstrate with confidence that its important business services rest on a compliant technology foundation.

The Bank of England's Supervisory Statement SS2/21 explicitly requires regulated firms to maintain robust ICT asset management practices. While the statement does not single out software licensing by name, any supervisor reviewing a firm's ICT asset management programme will expect to see evidence that software entitlements are tracked, licence positions are maintained, and vendor agreements are understood at a sufficient level of detail to support impact assessments. Firms that cannot demonstrate this will face supervisory feedback that accelerates their investment in software asset management capabilities.

The Financial Services Software Stack: Where Licensing Risk Concentrates

Financial services organisations typically run dense, complex software estates. The combination of legacy core banking or insurance platforms, market data infrastructure, risk and analytics systems, enterprise ERP and CRM applications, and a growing SaaS layer creates licensing complexity that most industries do not encounter. Understanding where risk concentrates is the first step in prioritising remediation effort.

Core Banking and Insurance Platforms

Legacy core banking platforms from vendors such as Temenos, Finastra, and FIS often carry complex licence structures that reflect the technology of the era in which they were originally deployed. Processor-based licensing has evolved as these platforms have migrated to virtualised and cloud environments, and many financial services organisations are running deployments that have drifted from the original contractual terms without either party explicitly acknowledging it. An IBM-powered core banking environment — for example, one running on IBM Z mainframe hardware with supporting middleware — will typically have licensing requirements governed by both processor-based metrics and ILMT sub-capacity rules for distributed software components. Failing to correctly configure and run ILMT means that sub-capacity licensing is not valid, and the full processor count becomes the metric IBM would use in an audit. This exposure can be substantial in a mainframe-heavy financial services environment.

Insurance platforms running Oracle Database at the back end face analogous risks. Oracle's licensing in virtualised environments remains a contentious area. Oracle's hard partitioning versus soft partitioning rules determine whether a financial services firm with an Oracle Database deployment on VMware infrastructure is licensing the individual VM or the entire physical host. Many firms have VMware estates that Oracle would classify as soft partitioning, making the entire host's processor count the relevant metric — a finding that regularly produces seven-figure true-up exposures in insurance and banking environments.

Market Data and Analytics Infrastructure

Market data platforms, trading analytics systems, and risk engines often run on high-performance infrastructure where per-processor or per-core licensing metrics translate directly into significant licence costs. Firms that have added compute capacity to meet performance requirements without triggering a licence review — a common pattern when infrastructure teams and software asset management teams operate independently — frequently discover that their deployed compute exceeds their licenced entitlement. In a vendor audit, the exposure figure is calculated at list price, and financial services organisations rarely receive the sympathy of a swift remediation agreement that non-regulated industries might negotiate.

Microsoft 365 and Cloud Migrations

Many financial services organisations have made substantial Microsoft 365 and Azure investments, sometimes replacing on-premises infrastructure, sometimes adding cloud capacity alongside it. The licence implications of hybrid deployments — where some workloads remain on-premises under traditional licensing arrangements while others have moved to Azure under consumption or subscription agreements — are complex. Microsoft's licensing terms for Azure use rights, Server and Cloud Enrolment (SCE) agreements, and the interaction between on-premises SQL Server licences and Azure SQL Database entitlements require careful management. Firms that have moved workloads to Azure without reviewing on-premises licence implications sometimes find they are paying twice: once for the retained on-premises entitlements and once for the cloud consumption.

Third-Party Software Governance: A Regulatory-Grade Approach

A regulatory-grade approach to third-party software governance in financial services goes beyond standard software asset management. It incorporates the contract intelligence, risk assessment, and documentation requirements that regulators expect to see when they review ICT risk management frameworks.

Vendor Register with Criticality Classification

Every financial services firm subject to DORA or FCA operational resilience requirements should maintain a vendor register that classifies software vendors by the criticality of the services they provide. Critical vendors — those whose unavailability, breach, or termination would impair important business services — require a higher standard of contractual governance, more frequent licence position reviews, and documented contingency plans. The vendor register should be a living document, updated with every new software purchase or renewal, and reviewed quarterly against the firm's current important business services mapping.

Contractual Compliance Reviews

At each major contract renewal, the firm's legal, procurement, and software asset management teams should jointly review the existing agreement against both the firm's deployment reality and the regulatory contractual requirements. The review should confirm that the agreement reflects how the software is actually deployed (catching any licence drift before the vendor's audit team does), that the contractual terms meet DORA or FCA operational resilience requirements where applicable, and that renewal terms are commercially optimal given the firm's usage data and market benchmarks.

Audit Readiness Programme

Financial services organisations should maintain a continuous audit readiness posture rather than scrambling to build a licence position in the 60 days after a vendor audit notification arrives. A financial services-grade audit readiness programme maintains validated licence positions for all tier-1 vendors updated at least quarterly, conducts mock internal audits for the three or four vendors with the highest audit risk (typically Oracle, IBM, SAP, and Microsoft), and maintains a documented remediation log showing how identified compliance gaps were resolved. This posture serves both vendor audit defence and regulatory ICT governance requirements simultaneously.

Financial Services Licensing: Benchmarks From the Field

Across financial services engagements, IBM, Oracle, and Microsoft account for the majority of audit exposures by value. The combination of regulatory scrutiny under DORA and aggressive vendor audit programmes makes financial services organisations disproportionately targeted. For IBM licensing advisory specialists and Oracle licensing advisory specialists with financial services sector experience, see our dedicated service pages.

Cost Optimisation in Financial Services: Constraints and Opportunities

Financial services organisations often assume that the regulatory and reputational costs of aggressive licence negotiation or optimisation outweigh the financial benefits. This is a mistake. The discipline required to manage licensing compliance rigorously is the same discipline that produces the data needed to negotiate vendor contracts effectively. A firm with a current, validated Oracle licence position is also a firm that knows exactly what it needs at renewal — and can push back credibly when Oracle's renewal quote includes entitlements that usage data shows are not being deployed.

Several cost optimisation opportunities are particularly relevant in financial services. First, consolidating vendor relationships: many financial services firms have accumulated point licences with the same vendor across multiple business units, often at different price points and with different contractual terms. Consolidating these into a single enterprise agreement — ideally with contractual protections around audit rights, price stability, and service continuity — typically reduces total spend and regulatory governance complexity simultaneously. Second, right-sizing at renewal: the discipline of comparing licence entitlements to actual deployment data before renewing is consistently the most immediate source of savings. In complex financial services environments, the gap between purchased licences and deployed licences is frequently material. Third, SaaS rationalisation: the growth of SaaS adoption in financial services — driven by cloud-first initiatives, digital transformation programmes, and departmental purchasing decisions — has created significant duplication across business units. A centralised review of SaaS applications frequently identifies multiple tools performing the same function at different price points, with combined licence costs that could be reduced substantially through consolidation onto a single preferred platform.

Practical Steps for Financial Services Licensing Leaders

For the CIO, CPO, or Head of Software Asset Management in a regulated financial services organisation, the practical priority list looks like this. Start with the DORA vendor register: if you do not have a complete, current register of all software vendors classified by ICT criticality, that is the regulatory requirement with the most immediate deadline and the broadest applicability. Build or update the register before your next supervisory engagement. Next, conduct a licence position audit for your top-five vendors by spend and regulatory criticality. These are the relationships where the combination of financial exposure and regulatory governance risk is highest. A current, documented licence position for Oracle, Microsoft, IBM, SAP, and your core banking or insurance platform vendor is the minimum acceptable standard for a DORA-compliant ICT governance programme. Then, audit your major software contracts against DORA's contractual requirements. Flag any agreements that lack the termination rights, data return provisions, or audit rights that DORA mandates, and prioritise these for remediation at next renewal. Finally, establish a renewal calendar that gives your team at least 90 days of lead time before each major contract expiry. Financial services organisations that allow vendor relationships to auto-renew — whether through inattention or because the internal renewal process is not triggered early enough — consistently pay more than their peers for equivalent software, and miss the opportunity to address contractual gaps before they become regulatory findings.