Banking & payments | Modelled case study
Rehearse an HSM-backed signing-key rollover without payment downtime
Can old and new signing trust coexist long enough to rotate safely across every payment participant?
The modelled organisation
A recognisable problem reaches the operating agenda
This composite scenario follows the PKI Lead · HSM Operations · Payments SRE functions. It is grounded in the cited problem context but does not identify a real customer.
Operating environment
A regulated bank operates real-time and batch payment services across internal platforms, clearing schemes, processors, HSMs, fraud controls, and external counterparties.
What is at stake
A cryptographic change must preserve authorization, settlement finality, scheme interoperability, evidence retention, and uninterrupted customer access.
Situation
A key rollover can strand terminals or counterparties when trust stores, key identifiers, validation code, and rollback ownership change at different speeds.
Event that forces action
Key expiry, algorithm deprecation, suspected compromise, or an HSM estate refresh.
Concrete system boundary
Systems this case study puts in scope
The model is specific about the operational surfaces that must be discovered, changed, or independently checked.
production and recovery HSMs
signing services
participant trust stores
payment validation and rollback paths
Modelled case study walkthrough
How this organisation would use QNSI
The walkthrough connects the real-world problem to a bounded QNSI contribution and an independently reviewable result.
Recognise the operating condition
A key rollover can strand terminals or counterparties when trust stores, key identifiers, validation code, and rollback ownership change at different speeds.
Frame the decision the owners must make
Can old and new signing trust coexist long enough to rotate safely across every payment participant?
Apply QNSI to the controlled boundary
Model key states and policy transitions in QNSI, record dual-validation windows, and exercise the customer-controlled custody path before production cutover.
Leave the team with a concrete result
A signed rollover runbook with prechecks, trust-overlap evidence, abort thresholds, and retirement confirmation.
Prove the result in the organisation's environment
Operations must prove the exact provider, module, firmware, mechanism, certificate owner, and recovery procedure in its deployment.
What useful success looks like
A decision artifact plus proof from the real environment
The model stops at a target result. It becomes an actual case study only when a customer produces and independently validates this evidence in production.
Decision artifact
A signed rollover runbook with prechecks, trust-overlap evidence, abort thresholds, and retirement confirmation.
Independent validation boundary
Operations must prove the exact provider, module, firmware, mechanism, certificate owner, and recovery procedure in its deployment.
Real-world problem grounding
Primary sources behind the model
These sources establish the external requirement, failure mode, or risk context used to model this case. They do not endorse HEOSSI or prove that QNSI completed the scenario.
Customer evidence status
This is modelled, not a customer claim
The organisation is a composite and the result is a target state. This page does not prove a deployment, customer outcome, certification, legal conclusion, regulator endorsement, or completed control.