Non-Functional Requirements That Actually Matter for Regulated Banking Platforms

Non-functional requirements are the section of the FRD that teams skim through and vendors skim past. They are the part of the specification that describes how the system behaves in operation: how fast, how available, how resilient, how secure, how compliant. In regulated banking, NFRs are not optional extras appended to the functional spec. They are the properties that determine whether the platform can legally operate, whether the firm is operationally resilient under DORA, and whether the firm's senior managers can discharge their attested accountabilities.

This post covers the NFR categories that matter for regulated banking platforms, how to specify each one so it is testable, the failure modes we see most often, and how NFRs connect to the broader regulatory and governance stack.

Why NFRs carry regulatory weight

Under DORA, financial entities must maintain ICT systems that are reliable, resilient, and capable of supporting critical or important functions under both normal and stressed conditions. Article 6 requires the ICT risk management framework to address every NFR dimension explicitly. Article 9 requires protection and prevention measures (security NFRs). Article 11 requires detection mechanisms. Articles 12 and 13 require response and recovery. The operational resilience regime in the UK, set out in the FCA and PRA policy statements, has parallel requirements.

These are not good-practice aspirations. They are supervisory expectations with prescribed enforcement. Banking platforms that do not specify and demonstrate NFRs fail DORA and operational resilience reviews.

The NFR categories that matter

Six categories cover the NFR landscape for regulated banking. Each has specific supervisory angles.

1. Availability

How often the system is operational during the windows it is supposed to be operational. Classic targets: 99.9 percent, 99.95 percent, 99.99 percent. The regulated angle: availability targets must be set by business service, not by technical component. A customer payment service that is 99.99 percent available at the service level is what matters, not whether any individual component meets an availability target.

Under DORA, availability is assessed against the impact tolerance for the critical or important function. If a payment disruption of more than 30 minutes has material impact, the availability NFR must be specified so that disruptions above 30 minutes are within the risk appetite. The availability NFR ties directly to the operational resilience impact tolerance, not to a generic uptime target.

2. Latency and throughput

How fast the system responds and how much it can handle. Latency NFRs should be specified at percentile (p95, p99) rather than average, because averages hide tail behaviour. Throughput NFRs should specify both sustained and peak loads, with peak load defined by a named scenario (year-end processing, pay day, market open).

The regulated angle: for trading systems under MIFID II, latency has specific implications for best execution. For payment systems under PSD3, response times are regulated for specific transaction types. The NFR must be anchored to the regulatory obligation, not to a generic performance target.

3. Recovery and resilience

How quickly the system can be restored after a failure, and how completely. Recovery Time Objective (RTO) is how fast. Recovery Point Objective (RPO) is how much data loss is tolerable.

Under DORA and operational resilience, both RTO and RPO are not simply IT targets. They are business decisions about the impact tolerance for the critical function the system supports. An RTO of four hours that leaves 500,000 customer payments stranded is not a compliant NFR even if the IT function can technically meet it. The NFR must be set by reference to the business service it supports.

Resilience NFRs extend beyond RTO and RPO to include the system's ability to degrade gracefully, fail over to alternate sites, and maintain regulatory reporting under adverse conditions. Geographical distribution, disaster recovery testing frequency, and chaos engineering practices belong here.

4. Security

Confidentiality, integrity and authenticity of data and transactions. Authentication strength (MFA, biometrics, device binding), encryption standards (in transit, at rest, in use), access control models (RBAC, ABAC, zero trust), vulnerability management cadence, incident detection capabilities.

The regulated angle: specific regulatory requirements for strong customer authentication under PSD3, for encryption of personal data under GDPR, for key management and cryptographic lifecycle under the FCA Cloud Guidance, and for security testing under DORA Article 24. Security NFRs cite the applicable regulatory requirement and show how the NFR meets it.

5. Data retention and auditability

How long data is kept, how it is retrieved, how its integrity is preserved, how access is logged.

The regulated angle: retention is regulated by many regimes. MIFID II requires order and transaction records retained for five years. GDPR limits retention to no longer than necessary for the stated purpose. AML regulations require transaction records retained for five years. FCA handbook provisions set specific retention requirements for different record types. The retention NFR is a table that specifies, for every material data category, the retention period, the retention rule source, and the retrieval SLA.

Auditability is adjacent. Every regulated action must be logged with sufficient detail to reconstruct what happened, when, and on whose authority. The audit log is a first-class NFR, not an afterthought.

6. Observability and monitoring

The system's ability to surface its own state in production. Metrics, logs, traces, alerts, dashboards.

The regulated angle: under DORA, firms must detect anomalous activities and ICT-related incidents in a timely manner. This is an observability NFR. The specification must address which events are logged, at what granularity, with what retention, and which events trigger which alerts. For the AI systems that support regulated decisions, observability extends to model drift detection, input distribution monitoring, and outcome fairness monitoring. The EU AI Act imposes specific monitoring obligations on high-risk AI systems.

Specifying NFRs so they are testable

Every NFR has four attributes that make it testable. Without all four, the NFR is aspirational.

Attribute 1: quantification

A number with a unit. "Highly available" is not an NFR. "99.95 percent available over any rolling 28-day window" is.

Attribute 2: measurement method

How the number is measured. By whom, using what instrument, at what frequency, with what sampling approach. "Measured continuously by the central observability platform using synthetic transactions at 60-second intervals".

Attribute 3: conditions of measurement

Under what operating conditions. Peak load, stressed load, degraded infrastructure. An availability target that holds only under optimal conditions is a partial NFR. The regulatory frame is explicit: NFRs must hold under conditions the firm expects to encounter, including the stressed scenarios used for operational resilience testing.

Attribute 4: acceptance and exception

What happens if the measurement falls below target. The NFR specifies the threshold that triggers incident response, the threshold that triggers regulatory reporting (under DORA Article 17), and the escalation path. The NFR is not complete without the exception path.

Worked examples

NFR-AVL-001

• Category: Availability
• System: Retail payment platform
• Statement: The retail payment platform shall be available for customer-initiated transactions during defined operating hours (24x7x365 excluding maintenance windows) at 99.95 percent over any rolling 28-day window.
• Conditions: Under normal and severe but plausible conditions as defined in the operational resilience scenarios.
• Measurement: Synthetic transactions at 60-second intervals from two geographically separated probes, availability calculated as successful synthetic transactions divided by total, excluding notified maintenance windows.
• Exception: Below 99.95 percent triggers a major incident review and DORA reporting if thresholds in Article 17 are met.
• Regulatory reference: DORA Article 6, operational resilience impact tolerance for the payment service (2 hours maximum disruption).

NFR-LAT-001

• Category: Latency
• System: Strong customer authentication service
• Statement: For 95 percent of authentication requests from the retail channel, the SCA service shall respond within 2000 milliseconds measured from the channel's request dispatch to the channel's receipt of the final authentication outcome.
• Conditions: Under normal load up to 800 requests per second sustained and 2000 requests per second peak.
• Measurement: Real user monitoring in the channel with sampling at 10 percent, aggregated daily and reported in the SLA dashboard.
• Exception: Below 95 percent triggers service performance review and capacity assessment. Below 80 percent triggers incident response.
• Regulatory reference: PSD3 RTS on SCA, internal SCA performance policy.

NFR-REC-001

• Category: Recovery
• System: Core banking ledger
• Statement: In the event of a site failure, the core banking ledger shall recover to a consistent state at an alternate site within 60 minutes (RTO) with no more than 30 seconds of committed transaction loss (RPO).
• Conditions: Including loss of primary site and primary database, with secondary site fully functional.
• Measurement: Annual recovery exercise plus quarterly desktop exercise, with formal evidence retained.
• Exception: Missed RTO or RPO in exercise triggers remediation workstream and reporting to ICT risk committee.
• Regulatory reference: DORA Article 12, operational resilience impact tolerance for the ledger service.

Common failure modes

Failure: NFRs as an appendix

The NFR section of the FRD is a page at the end listing "high availability, good performance, secure". Meaningless. Fix: NFRs are a first-class section with quantified, measured, conditioned, exception-handled statements for every category.

Failure: technical NFRs without business anchor

NFRs are set by the technology function in isolation. 99.99 percent availability, because that is a standard target. The business may only need 99.9 percent, or may need 99.995 percent depending on impact tolerance. Fix: NFRs are set by reference to the business service's impact tolerance, not by technology convention.

Failure: peak load never tested

The throughput NFR specifies 2000 transactions per second. The load testing regime only exercises 800 TPS because that is the current typical load. Peak is untested. When year-end arrives, the system fails. Fix: NFRs are tested at the peak scenarios they specify, regularly, with documented evidence.

Failure: retention table missing or incomplete

Retention NFRs are incomplete. Several data categories are not covered. When GDPR or MIFID II questions arrive, the firm cannot answer cleanly. Fix: retention NFRs are a comprehensive table covering every material data category, with source, period, and retrieval SLA.

Failure: observability at deployment only

Observability is implemented for the launch but decays over time. Alerts fire for known issues and not for new issues. Fix: observability NFRs include the alerting taxonomy and its maintenance discipline, and are reviewed at a cadence matched to system change rate.

Connection to the artefact stack

NFRs do not stand alone. They connect to:

• The requirements traceability matrix: every NFR traces to a regulatory obligation or business service impact tolerance.
• The data lineage mapping: data retention NFRs depend on knowing where data lives.
• The DORA third-party register: NFRs in vendor contracts must align with the firm's internal NFRs.
• The business capability map: NFRs attach to business capabilities, not to technical components.

These connections are what make NFRs operationally useful rather than paperwork.

External references

The ISO/IEC 25010 systems quality model provides a canonical taxonomy of software quality attributes that maps well to the NFR categories in this post. The NIST SP 800-53 security controls provides a comprehensive control set for the security NFR category. The FCA operational resilience policy provides the UK regulatory framing for availability, recovery and resilience NFRs.

The short version

NFRs in regulated banking are regulatory artefacts, not technical afterthoughts. Six categories (availability, latency, recovery, security, retention, observability) each require quantified targets, measurement methods, operating conditions and exception paths. Targets are anchored to business impact tolerance, not to technical convention.

Programmes that treat NFRs as a first-class section of the requirements deliver platforms that satisfy DORA, PSD3, MIFID II and operational resilience supervision. Programmes that treat them as appendix material find their NFR gaps during the first major incident or the first supervisory review.

Our business analysis service and financial systems implementation service cover the NFR discipline as part of the integrated delivery stack for regulated platforms.