Let Digiqt design an ALM IRRBB system where every reported number traces back to the contracts and assumptions that produced it.

Make Your Rate Risk Numbers Defensible

# Building an ALM Platform That Survives a Rate Shock and an Audit

Asset liability management systems fail their owners in a particular way. The engine calculates correctly, the reports produce plausible numbers, and then a supervisor asks why the economic value of equity moved fourteen percent between two quarters, and nobody can decompose the answer into portfolio change, assumption change, and model change.

That question is the real design requirement. An ALM IRRBB system is not primarily a calculation platform, because the mathematics has been settled for decades. It is a data lineage and reproducibility platform that happens to compute interest rate sensitivities, and teams that scope it the other way around build something that works until it is questioned.

## What does an ALM and IRRBB system have to produce?

Economic value of equity and net interest income sensitivities under standardised shocks, with disclosure and an outlier test.

The Basel Committee's standards for interest rate risk in the banking book, issued in April 2016, set out both measurement approaches: economic value of equity, which assesses the impact of rate changes on the value of the bank, and net interest income, which measures earnings sensitivity over defined horizons. Banks apply standardised interest rate shocks so exposures are comparable, quantitative disclosures are based on those common scenarios, and the outlier identification threshold was tightened to fifteen percent of Tier 1 capital.

### Why do two measures need two different pipelines?

Because one values the whole balance sheet in run-off and the other projects earnings on a going-concern basis.

Economic value of equity discounts all future cashflows and is sensitive to long-dated positions and to the discount curve. Net interest income projects income over a shorter horizon and is sensitive to repricing behaviour, new business assumptions, and margin decisions. They can move in opposite directions from the same shock, which is not an error and is one of the more useful things the pair tells you. Architecturally that means a shared cashflow model with two distinct downstream calculations and two distinct sets of assumptions, rather than one pipeline with a flag.

### Why does disclosure shape the architecture?

Because anything disclosed must be reproducible from stored inputs long after the run.

A number that appears in a public disclosure or a board pack has to be reconstructable a year later, with the model version, assumption set, and portfolio snapshot that produced it. That single requirement drives immutability, versioning, and lineage throughout the platform, and it is far cheaper to build in from the start than to retrofit under audit pressure. The regulatory expectations behind that trail are set out in this guide to [data lineage and audit trails](https://digiqt.com/blog/audit-ready-ci-cd-financial/).

> **Can you decompose a quarter-on-quarter move into portfolio, assumption, and model change?**
>
> [Talk to Digiqt about an ALM data and lineage assessment](https://digiqt.com/contact-us/)

## Where does the data come from, and why is that the hard part?

From every product system in the bank, most of which were never designed to expose repricing attributes.

The calculation needs contractual detail that product systems hold implicitly, in fields designed for servicing rather than risk. Assembling it is where ALM programmes spend most of their time and where their credibility is decided.

| Data domain | What ALM needs | Common problem |
|---|---|---|
| Loans and mortgages | Repricing dates, rate basis, caps, floors, prepayment terms | Optionality held in free text or product codes |
| Deposits | Contractual maturity where it exists, rate basis, notice terms | No contractual maturity for the largest balances |
| Wholesale funding | Cashflows, embedded options, call dates | Held in treasury systems with a different product model |
| Derivatives and hedges | Full cashflow legs, hedge designation | Hedge accounting relationships not machine-readable |
| Off-balance-sheet commitments | Drawdown behaviour | Frequently omitted entirely |
| Market data | Curves, volatilities, historical rates | Multiple sources with no single authority |

### Which contractual attributes matter most?

Repricing date, rate basis, and every embedded option, because those three drive the answer.

If you capture nothing else accurately, capture when each position reprices, what it reprices against, and what optionality exists on either side. Caps, floors, prepayment rights, and early withdrawal terms change the shape of a shock response materially, and a portfolio where they are approximated produces sensitivities that look precise and are not. Where a product system genuinely cannot supply an attribute, record the substitution explicitly as an assumption rather than defaulting silently, so its impact can be measured and challenged.

### How do you handle products with no contractual maturity?

With explicit behavioural assumptions, held as versioned data and backtested against actual behaviour.

Non-maturity deposits are the largest modelling judgment on most banking books, and the assumption about what share is stable and how it reprices moves economic value of equity more than most portfolio decisions. Prepayment behaviour on fixed-rate lending is the second. Both must be modelled as declared assumptions with an owner, an effective date, supporting analysis, and a backtest against realised behaviour. The pressure this creates in a rising rate environment is exactly what this analysis of pricing in a rising interest rate world describes on the liability side of a different balance sheet.

## How should behavioural assumptions be governed?

As first-class versioned artefacts with owners, effective dates, evidence, and an approval trail.

Assumptions embedded in calculation code are the single most common reason an ALM platform cannot answer a supervisor's question. Hold them in a store where each assumption has an identifier, a value or curve, an effective date range, a named owner, the analysis supporting it, and the committee approval that adopted it. Then every run records which assumption set it used. That structure makes assumption change a measurable component of any movement, which is what turns an unexplainable variance into a three-line decomposition. The governance discipline mirrors what this look at operationalising a new scenario framework without model-change chaos describes, where the controls around change matter more than the model itself.

## How should the calculation engine be architected?

As a deterministic, reproducible pipeline with scheduled official runs and isolated on-demand analysis.

Official runs for regulatory and board reporting must be reproducible from immutable inputs: portfolio snapshot, market data snapshot, model version, assumption set version. On-demand what-if runs for the business need to be fast and freely available, and must never be able to overwrite or be mistaken for an official result. Separate them by design, tag every result with its run type, and make the provenance visible in whatever tool consumes it.

### Batch, on demand, or both?

Both, with different guarantees rather than different code.

Use the same engine for both so results are comparable, and differentiate by input handling and retention. Official runs freeze inputs and retain results indefinitely. Analytical runs may use the latest available data, are retained for a shorter period, and are always labelled. Where users need speed, invest in incremental recalculation and caching of the expensive cashflow generation step rather than maintaining a second simplified engine, because two engines guarantee two answers and a standing argument about which is right.

### What makes a run reproducible a year later?

Immutable input snapshots, versioned model and assumptions, and stored results with full lineage.

Reproducibility is an engineering property, not a policy. Snapshot inputs rather than querying live systems at run time, version the model as an artefact rather than as whatever was deployed that day, record the assumption set identifier, and store the result together with intermediate cashflows if storage allows. Then provide a decomposition capability that attributes any change between two runs to portfolio movement, market data, assumption change, or model change. That single feature is what earns the platform its credibility.

> **Rebuilding last quarter's ALM numbers by hand when questions arrive?**
>
> [Talk to Digiqt about reproducible risk calculation pipelines](https://digiqt.com/contact-us/)

## How do you handle scenario volume without the platform becoming unusable?

By treating scenarios as data and planning for hundreds of runs rather than a handful.

| Scenario set | Purpose | Typical count |
|---|---|---|
| Standardised interest rate shocks | Regulatory measurement and disclosure | Six common scenarios |
| Internal management scenarios | Business planning and risk appetite | Ten to thirty |
| Assumption sensitivities | Showing dependence on judgment | One per key assumption, often dozens |
| Stress and reverse stress | Severe but plausible, and breaking-point analysis | Five to fifteen |
| Ad hoc analysis | Answering a specific question this week | Unbounded |

The regulatory set is small and the total is not, because sensitivity analysis multiplies. Design the engine for parallel execution across scenarios, make scenario definition a configuration artefact rather than a code change, and report the standardised set alongside the internal view so the board sees both the comparable number and the one that reflects your actual balance sheet. Cross-border balance sheets add another dimension, since currency and jurisdictional segmentation interact with rate risk in the way described in asset-liability mismatch under geoeconomic fragmentation.

## How should ALM connect to funds transfer pricing and treasury?

Through shared curves, a shared cashflow model, and a shared assumption set, with one owner for each.

When the ALM system and the funds transfer pricing engine use different curves or different behavioural assumptions, the bank prices business against one reality and reports risk against another. Business units then optimise against pricing signals that do not correspond to the risk being reported, and nobody can reconcile the two without a project. Share the inputs, keep one owner per curve and per assumption, and treat any divergence as a defect. The design consequences on the pricing side are covered in [funds transfer pricing engine design](https://digiqt.com/blog/funds-transfer-pricing-engine/), and the intraday and positioning side connects to the [real-time treasury platform](https://digiqt.com/blog/real-time-treasury-platform/) that supplies actual cash behaviour for backtesting.

## What governance must the platform support?

Model risk controls, assumption approval, change management, and independent validation.

The platform has to make governance cheap or governance will be performed on spreadsheets alongside it. That means model inventory registration, an approval workflow for assumption changes with evidence attached, change control that ties a model version to an approval, and the ability for independent validation to rerun a result without help from the team that built it. Access control matters too: the people who set assumptions, run official reports, and approve changes should be distinguishable in the audit trail. None of this is exotic engineering, and all of it is far cheaper to build before the first validation review than after.

## How should delivery be phased?

Data foundation first, then a single measure end to end, then the second measure, then scenario scale.

| Phase | Duration | Deliverable |
|---|---|---|
| Data foundation | 4 to 6 months | Contractual attribute capture, product coverage map, market data authority |
| First measure end to end | 3 to 4 months | Cashflow model plus one measure, reproducible official run |
| Assumption framework | 2 to 3 months | Versioned assumption store, ownership, backtesting |
| Second measure and disclosure | 2 to 3 months | Both measures, standardised shocks, disclosure outputs |
| Scenario scale and decomposition | 2 to 4 months | Parallel scenario execution, movement attribution |
| Integration with pricing and treasury | Ongoing | Shared curves and assumptions, feedback from realised behaviour |

Do not start with the engine. A well-implemented calculation over incomplete contractual data produces confident wrong answers faster, and the data phase is the one that determines whether anything downstream is defensible.

## Which metrics show the platform is healthy?

Data coverage and attribute completeness, run reproducibility, time to produce an official run, decomposition capability, and backtest accuracy.

Track the share of balance sheet value covered by directly sourced contractual attributes rather than approximations, because that number is your credibility ceiling. Measure attribute completeness per product and drive the gaps down deliberately. Test reproducibility by rerunning a prior official run and confirming identical output, and treat any failure as a serious defect. Watch the elapsed time to produce an official run, since a process that takes three weeks cannot support decisions. And backtest behavioural assumptions against realised behaviour on a regular cycle, reporting the error so assumption quality is visible rather than assumed.

An ALM platform earns its keep on the day someone senior asks a hard question about a number. The institutions that answer in an afternoon are not the ones with the most sophisticated models. They are the ones that stored their inputs, versioned their assumptions, and can show exactly where a number came from.

## Frequently Asked Questions

### What must an IRRBB system actually produce?

Economic value of equity and net interest income sensitivities under standardised interest rate shock scenarios, with disclosures and an outlier test against Tier 1 capital.

### Why is data capture harder than the calculation?

Because the maths is well defined while the contractual attributes it needs, repricing dates, caps, floors, optionality, and prepayment terms, are scattered across product systems that never had to expose them.

### How do you model products with no contractual maturity?

With explicit behavioural assumptions such as core deposit stability and prepayment rates, documented, versioned, and backtested rather than embedded in calculation code.

### Why do behavioural assumptions need version control?

Because a supervisor will ask what you assumed on a specific date and why. Assumptions held as data with an owner, effective dates, and evidence answer that in minutes.

### Should the engine run in batch or on demand?

Both. Regulatory and board reporting run as scheduled reproducible batches, while business teams need on-demand what-if runs that never overwrite an official result.

### How many scenarios does the platform need to handle?

Standardised shocks plus internal scenarios, plus sensitivities per assumption, which multiplies quickly. Design for hundreds of runs rather than a handful.

### How does ALM connect to funds transfer pricing?

They should share the same curves, cashflow model, and assumption set. When FTP and ALM disagree, business decisions get priced against a different reality than the one being reported.

### What makes a run defensible months later?

Immutable inputs, a recorded model and assumption version, a stored result, and lineage from any reported figure back to the contracts that produced it.

## Sources

- [BCBS, Interest rate risk in the banking book](https://www.bis.org/bcbs/publ/d368.htm)
- [BCBS, Principles for Sound Liquidity Risk Management and Supervision](https://www.bis.org/publ/bcbs144.htm)
- [BCBS, Monitoring tools for intraday liquidity management](https://www.bis.org/publ/bcbs248.htm)

ALM IRRBB System Design for Interest Rate Risk in the Banking Book

Let Digiqt help you define critical business services, set impact tolerances, and test whether your platform can hold them.

Set Tolerances You Can Defend

# Deciding How Much Disruption Your Customers Can Actually Absorb

Operational resilience programmes usually begin with a list of systems and a set of recovery time objectives that were agreed years ago by people who no longer work there. The numbers look precise, they were never derived from customer harm, and nobody has tested whether the platform can meet them.

The regulatory shift over the last few years asks a different question. Not how quickly can you restore a database, but how long can a customer be unable to make a payment before real harm occurs, and can you prove you would stay inside that limit under a severe but plausible disruption. Setting an operational resilience impact tolerance you can defend means starting from the outside and working in, which is the opposite of how most technology organisations think.

## What is a critical business service?

Something the customer or the market receives, defined by outcome rather than by system or department.

The distinction sounds semantic and it changes everything. Payments processing is a system. Being able to make a payment is a service. Once the service is defined that way, its dependencies cross every internal boundary, which is exactly the point: disruption reaches customers through whichever dependency fails, not only through the one your team owns.

### Why does the service definition decide everything downstream?

Because mapping, tolerance, testing, and investment all inherit its scope.

Define the service too narrowly and you exclude the dependency that will actually cause the outage. Define it too broadly and the tolerance becomes meaningless because it aggregates unrelated failure modes. Get it wrong and every artefact built on it inherits the error, which is why the definition deserves more senior attention than it usually receives. The Basel Committee's Principles for operational resilience, published in March 2021, take a principles-based approach precisely so institutions can apply this thinking to their own structures rather than following a template.

### How many services should a bank have?

Usually between ten and thirty, depending on size and complexity.

Fewer than ten and the tolerances become so broad that nothing fails them. More than fifty and the mapping and testing burden makes the programme unaffordable, while genuinely critical services get lost among marginal ones. Draw the line at services whose disruption would cause intolerable harm to customers, threaten market integrity, or breach a regulatory obligation, and be prepared to defend the exclusions as well as the inclusions.

> **Is your resilience programme organised around systems or around what customers receive?**
>
> [Talk to Digiqt about defining critical business services](https://digiqt.com/contact-us/)

## What exactly is an impact tolerance?

The maximum disruption a service can sustain before causing intolerable harm, expressed from the outside in.

It is not an internal target and not an aspiration. It is a limit, set by reference to customer and market harm, that the institution commits to staying within under severe but plausible conditions. That makes it a board-level statement about risk appetite with direct engineering consequences.

### How is it different from a recovery time objective?

A tolerance describes tolerable harm, while an RTO describes an internal restoration target.

| Aspect | Impact tolerance | Recovery time objective |
|---|---|---|
| Perspective | Customer and market | Internal technical |
| Scope | End-to-end business service | Component or system |
| Set by | Business owner, board approved | Technology and operations |
| Meaning | Limit that must not be breached | Target to aim for |
| Consequence of breach | Governance and supervisory issue | Missed internal objective |

The relationship runs one way. Tolerances constrain the RTOs of every component in the chain, and if the arithmetic of component RTOs cannot deliver the service tolerance, you have a gap to remediate rather than a tolerance to relax quietly.

### What should the tolerance be measured in?

Whatever expresses harm for that service, which is often time and not always.

Elapsed time is the default and it fits most access and payment services. Some services need volume, such as the number of payments not processed, or value, or the number of customers affected. Others need more than one dimension, since a short outage affecting everyone and a long outage affecting a few are different harms. Choose deliberately and state the metric, because a tolerance expressed in the wrong unit produces testing that measures the wrong thing.

## How do you set a tolerance you can defend?

From evidence about harm, owned by the business, approved by the board, and revisited after testing.

Start with what actually happens to customers as disruption extends: missed obligations, unpaid bills, inability to access funds, market positions unhedged. Use complaint data, past incident experience, and payment timing obligations as evidence rather than judgment alone. Then have the accountable business owner set the tolerance and the board approve it, since it is a statement about acceptable harm rather than a technical parameter. Technology's job is to say what is currently achievable and what closing the gap would cost.

### Why are first-pass tolerances usually wrong?

Because they are set optimistically and then contradicted by the first honest test.

Most institutions set generous initial tolerances, discover under testing that the platform cannot hold them, and then face a choice between remediation and revision. That is a healthy process if it is transparent and a governance problem if the tolerance quietly moves to match the tested result. Record the original tolerance, the tested outcome, and the decision, so the trail shows judgment rather than accommodation. Metrics that boards can actually use are discussed well in operational resilience metrics for boards.

## How should service mapping be done?

Across every layer the service depends on, derived from live data rather than drawn by hand.

| Layer | What to capture | Common gap |
|---|---|---|
| People | Roles and skills required, including out of hours | Single individuals with unique knowledge |
| Process | Manual steps, approvals, workarounds | Undocumented workarounds that carry the service |
| Technology | Applications, platforms, data stores, networks | Shared components under multiple services |
| Data | Datasets required, their currency and integrity | Data quality dependencies nobody mapped |
| Facilities | Locations, connectivity, physical access | Assumption that remote work always substitutes |
| Third parties | Providers and their own critical dependencies | Nth-party layers with no visibility |

### How deep should mapping go?

Deep enough to find the single points of failure, which usually means further than the first pass.

Stop when you have identified every dependency whose failure could breach the tolerance, not when the diagram looks complete. That typically means going below the obvious application layer into shared platform services, identity, network paths, and provider dependencies. Shared components are where the surprises are, because a queue service or an identity provider under several critical services concentrates risk invisibly, which is the same discovery problem addressed in [third-party and concentration risk](https://digiqt.com/blog/third-party-concentration-risk-cloud/).

### How do you keep the map current?

By deriving it from telemetry and deployment metadata rather than maintaining documents.

A hand-drawn map is stale within a quarter and misleading within two. Require deployed components to declare the service they support, derive dependency edges from observed calls and infrastructure definitions, and reconcile the derived map against the documented one so drift becomes a work item. That is the shift from static maps to live dependency data described in moving from critical-process maps to live dependencies, and it depends on the instrumentation covered in this guide to observability for core systems.

> **Could you produce today's dependency map for a critical service without a workshop?**
>
> [Talk to Digiqt about deriving service maps from live telemetry](https://digiqt.com/contact-us/)

## How do you test against tolerance?

With severe but plausible scenarios that name a real failure and measure the service outcome.

| Scenario | Tests | Frequency |
|---|---|---|
| Regional infrastructure failure | Failover capability against tolerance | Annually per critical service |
| Critical third-party outage | Substitutability and degraded mode | Annually |
| Data corruption requiring restore | Recovery integrity and elapsed time | Annually |
| Cyber incident with untrusted environment | Rebuild rather than restore | Annually |
| Key person unavailability | People dependency | Periodically |
| Simultaneous partial degradation | Combined effects and detection | Periodically |

### What counts as severe but plausible?

Extreme enough to challenge the service, grounded in something that has happened somewhere.

The test of plausibility is whether you can point to a comparable event in the industry, and the test of severity is whether the scenario could actually breach the tolerance. Scenarios that neither stretch the platform nor could ever occur are wasted cycles. CPMI-IOSCO's guidance on cyber resilience for financial market infrastructures, published in June 2016, frames the expectation as anticipating threats, responding rapidly, and achieving faster and safer target recovery objectives, which is a useful reminder that recovery capability is the thing being tested rather than the incident narrative.

### What happens when you cannot stay inside tolerance?

You record the gap, remediate on a dated plan, or revise the tolerance with stated justification.

All three are legitimate. What is not legitimate is discovering the gap and neither fixing nor disclosing it. Log it with an owner, an investment estimate, and a target date, report it through governance, and track closure. Where the required investment is disproportionate, the honest answer may be a revised tolerance with compensating measures, and a supervisor will generally accept a reasoned position far more readily than an unevidenced one.

## How does this connect to investment decisions?

It converts resilience spending from a technical argument into a business one.

This is the underappreciated benefit of the whole exercise. Once a tolerance is board approved and testing shows a gap, the investment case writes itself in terms the executive committee already accepted, which is a far stronger position than requesting redundancy funding on architectural grounds. It also works in reverse: services with generous tolerances and adequate current capability should not receive further hardening, which lets you redirect spending honestly. Where the gap is about failover capability specifically, the engineering choices and their costs are set out in [multi-region failover design and zero data loss](https://digiqt.com/blog/banking-multi-region-failover-rpo/).

## What governance and reporting is expected?

A documented self-assessment, board approval of services and tolerances, and evidence of testing and remediation.

Maintain a self-assessment that identifies the critical services, states the tolerances and their basis, describes the mapping, records scenario testing and results, lists gaps with remediation plans, and shows board approval. Keep it current rather than annual, since the questions arrive when an incident happens rather than on your reporting cycle. Third-party dependencies belong inside it, using the tools set out in the FSB's December 2023 toolkit for identifying critical third-party services and monitoring systemic dependencies, and resolution-related capabilities should be consistent with what you tell resolution authorities, which is covered in [recovery and resolution technology capabilities](https://digiqt.com/blog/recovery-resolution-planning-technology/).

## How should delivery be phased?

Services first, then tolerances, then mapping, then testing, then remediation.

| Phase | Duration | Deliverable |
|---|---|---|
| Service identification | 1 to 2 months | Ten to thirty services defined by outcome, with owners |
| Tolerance setting | 1 to 2 months | Metric, value, evidence, and board approval per service |
| Mapping | 3 to 5 months | Dependencies across all layers, derived from live data |
| Scenario design and testing | 2 to 4 months | Severe but plausible scenarios executed and measured |
| Gap remediation | Ongoing | Dated plans, owners, investment cases |
| Self-assessment and reporting | Continuous | Living document, board review cycle |

Do not start with mapping, tempting though it is for a technology team. Mapping without agreed services produces an enormous diagram nobody can act on, whereas mapping scoped by ten well-defined services is tractable and immediately useful.

## Which metrics prove the programme is real?

Tolerance coverage, tested coverage, gaps and their ageing, map freshness, and breaches in live incidents.

Report the share of critical services with board-approved tolerances and a stated metric. Report tested coverage separately, since an untested tolerance is an assertion. Track open gaps, their remediation dates, and their ageing, because ageing gaps are the clearest sign a programme has stalled. Measure map freshness as the share of dependencies derived automatically within a recent window. And record actual tolerance breaches during real incidents, which is the only unambiguous evidence of whether the tolerances and the platform agree.

Operational resilience work earns its keep when it changes what the institution builds and funds. If the tolerances are approved, the testing is honest, and the gaps are visible with owners and dates, the programme is doing its job. If it produces a self-assessment nobody has read since sign-off, it is documentation with a resilience label on it.

## Frequently Asked Questions

### What is a critical business service?

Something a customer or the market receives, such as making a payment or accessing funds, rather than a system or a department. The outcome defines it, not the technology delivering it.

### How is an impact tolerance different from a recovery time objective?

A tolerance is the maximum disruption the outside world can absorb before intolerable harm. An RTO is an internal target for restoring a component. Tolerances constrain RTOs, not the reverse.

### How many critical business services should a bank have?

Usually between ten and thirty. Too few makes tolerances meaningless, and too many makes mapping and testing unaffordable while obscuring what genuinely matters.

### What should a tolerance be measured in?

Whatever expresses harm for that service, commonly elapsed time, but sometimes transaction volume, value, or number of customers affected. Some services need more than one dimension.

### Who should set the tolerance?

The business owner accountable for the service, with evidence about customer harm, approved at board level. Technology sets what is achievable, not what is tolerable.

### What does severe but plausible mean?

A scenario extreme enough to challenge the service but grounded in real possibility, such as a region failure, a critical provider outage, or data corruption requiring restore.

### What happens when testing shows you cannot stay inside tolerance?

You record the gap, remediate with a plan and a date, or change the tolerance with justification. The gap is the finding, and hiding it is what turns a technical issue into a governance failure.

### How do you keep service maps current?

Derive them from live telemetry and deployment metadata rather than maintaining diagrams, because a documented map is out of date within a quarter of being signed off.

## Sources

- [BCBS, Principles for operational resilience](https://www.bis.org/bcbs/publ/d516.htm)
- [CPMI-IOSCO, Guidance on cyber resilience for financial market infrastructures](https://www.bis.org/cpmi/publ/d146.htm)
- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)

Operational Resilience: Mapping Services and Impact Tolerances

Let Digiqt benchmark quantum proposals against tuned classical baselines and design formulation work that pays off either way.

Evaluate the Claim Before You Fund the Programme

# The Honest Version of the Quantum Finance Business Case

Quantum computing arrives on a CTO's desk in a predictable form. A vendor deck showing a portfolio optimisation solved on quantum hardware, a competitor's press release about a research partnership, a board member asking what the institution's position is, and an internal enthusiast with a proposal. The pressure to have an answer is real and the quality of available information is poor, because the interesting results are published by parties with an interest in the outcome.

Evaluating quantum computing portfolio optimization proposals well is mostly a matter of asking a small number of unglamorous questions, of which one matters more than all the others combined.

## What is actually being claimed?

Usually that a quantum method solved a problem, which is different from solving it better.

Almost every demonstration in this space is genuine as stated and much narrower than it reads. A portfolio problem was solved on quantum hardware. That claim is compatible with the problem being small enough to solve on a laptop instantly, the quantum run taking longer, the comparison being against an untuned classical method, or the timing excluding the substantial cost of encoding the problem and reading out the result. None of that makes the work dishonest, and all of it makes the headline useless for a procurement decision.

### Why is the vendor claim rarely the published result?

Because the qualifications live in the paper and the headline lives in the deck.

Research papers in this field are typically careful, stating problem size, hardware conditions, comparison method, and limitations. By the time the result reaches a commercial audience the qualifications have been compressed out. The practical remedy is to read the underlying work rather than the summary, and to ask for it if it does not exist. A proposal with no reproducible underlying result is a research partnership rather than a technology purchase, and it should be evaluated on that basis.

> **Has anyone read the paper behind the deck you were shown?**
>
> [Talk to Digiqt about evaluating quantum proposals](https://digiqt.com/contact-us/)

## Which finance problems are candidates?

Four families, with different levels of theoretical support.

| Problem family | Finance use | Quantum formulation | Honest status |
|---|---|---|---|
| Constrained combinatorial optimisation | Portfolio selection with cardinality and lot constraints | Formulated as a quadratic unconstrained binary optimisation problem | Formulation mature, hardware advantage unproven at real scale |
| Stochastic simulation | Market and credit risk simulation, scenario generation | Amplitude estimation style approaches | Theoretical speedup argued, hardware requirements substantial |
| Derivative pricing | Path-dependent instrument valuation | Related simulation formulations | Same constraint as above |
| Machine learning and sampling | Feature selection, certain sampling problems | Various quantum machine learning proposals | Least settled, claims most contested |

The first row is where most vendor activity concentrates, because portfolio selection with real-world constraints is a genuinely hard combinatorial problem that institutions currently solve with heuristics and accept approximate answers for. That makes it a fair target. It also makes the classical comparison harder, because the incumbent is a well-tuned heuristic rather than an exact method, and beating it is a higher bar than the marketing implies. The wider issue of models lagging portfolio reality is examined in [capital models that lag portfolio change](https://digiqt.com/blog/model-risk-management-platform-sr-11-7/).

## What do the two hardware approaches suit?

Annealing targets optimisation directly; gate-based machines are general purpose and harder to build.

Quantum annealing is purpose-built for optimisation problems expressed in a particular binary quadratic form, which maps naturally onto portfolio selection. It is available at larger scale today and its advantage over strong classical methods remains contested. Gate-based quantum computing is the general-purpose model that the simulation and pricing speedups depend on, and it is further from the scale those algorithms require. A bank evaluating proposals should know which model a given claim rests on, because the two have different maturity, different vendors, and different problem fit, and conflating them is common in summarised material.

## What does current hardware actually support?

Less than the coverage suggests, and NIST's own framing is instructive.

NIST's quantum information science material describes quantum computers as a new kind of machine that can, in theory, simulate the fundamentally quantum nature of matter, alongside quantum sensors for ultra-high-precision measurement and quantum networks spanning cities and nations. The phrase worth noticing is "in theory". A national measurement science agency describing the field in those terms is a reasonable calibration point against commercial material describing production readiness.

### Why is qubit count the wrong headline number?

Because it describes the hardware's size rather than its usable capability.

What determines whether a machine can solve a problem is the combination of error rates per operation, how long the qubits maintain coherence, which qubits can interact with which others, and how much overhead error correction imposes to produce reliable logical operations from unreliable physical ones. A larger machine with worse error characteristics can be less useful than a smaller, cleaner one. When a proposal leads with qubit count and does not address error rates or correction overhead, that omission is the most informative thing in the document.

## How should a bank evaluate a specific claim?

With six questions, asked in order.

| Question | Why it matters | What a good answer looks like |
|---|---|---|
| What classical method was it compared against? | Determines whether the comparison is meaningful | A named, current, seriously tuned solver |
| Who tuned the classical baseline? | Untuned baselines produce flattering results | Someone with an interest in the classical side performing well |
| What size and structure was the problem? | Small instances prove nothing about scale | Realistic dimensions, stated explicitly |
| Was timing end to end? | Encoding and readout often dominate | Total wall-clock including all data movement |
| Is the result reproducible? | Single runs of stochastic methods mean little | Repeated runs with distribution reported |
| What happens as the problem grows? | Scaling behaviour is the whole question | Measured scaling across sizes, not asserted |

### Why is the classical baseline the whole evaluation?

Because the only question that matters is whether it beats what you would otherwise do.

A quantum result is interesting to a physicist regardless of what classical computers can achieve. It is interesting to a bank only if it produces a better answer, or an equally good answer faster or more cheaply, than the tuned classical approach the institution would use instead. That comparison is frequently weak in published work, sometimes because constructing a genuinely strong classical baseline is expensive and unrewarding for the party running the experiment. When evaluating a proposal, fund the classical side of the comparison yourself and treat it as the control. It is also worth noting how often the outcome of this exercise is a materially improved classical solution, which is a good result even though nobody writes a press release about it. Compute economics belong in the same analysis, as covered in [cloud cost optimisation for workloads at scale](https://digiqt.com/blog/cloud-migration-regulatory-approval-banking/).

## What is worth doing now?

Formulation work, which pays off regardless of what the hardware does.

The most valuable output of a quantum exploration in a bank is usually not quantum. Expressing a portfolio problem precisely, with its real constraints written down rather than embedded in the heuristic that currently approximates it, produces immediate benefit: classical solvers perform better on a clean formulation, the constraints become reviewable by risk and business stakeholders, and previously undocumented assumptions surface. If quantum hardware becomes useful, that formulation transfers directly. If it does not, the institution has a better-specified problem and a better classical answer.

The same applies to scenario and simulation work, where the discipline of stating the model precisely has value independent of what executes it, as discussed in operationalising an economic scenario generator and in the interest rate simulation machinery described in [ALM and IRRBB systems](https://digiqt.com/blog/alm-irrbb-system/).

### Why does formulation work pay off either way?

Because the constraint set is the asset, and it currently exists only inside a heuristic.

In most institutions the real portfolio constraints are partly documented, partly encoded in a solver's configuration, and partly maintained as folklore by two people. Writing them down completely is a prerequisite for any new approach, quantum or otherwise, and it exposes inconsistencies that have been quietly shaping decisions. That is a substantial deliverable from a programme whose headline objective may never be met, and it is the reason a modest exploration can be justified even by a sceptic. The same knowledge concentration problem is examined in [the legacy skills shortage](https://digiqt.com/blog/legacy-skills-shortage-banking-technology/).

> **Are your real portfolio constraints written down, or encoded in a solver nobody has revisited?**
>
> [Talk to Digiqt about problem formulation that outlasts the hardware question](https://digiqt.com/contact-us/)

## How does model risk management apply?

Fully, and the current guidance is not the one most institutions still cite.

Any output that informs a decision is a model output, regardless of the hardware that produced it. The Federal Reserve's SR 26-2, issued 17 April 2026, is the current model risk management guidance and supersedes SR 11-7 from 2011 and SR 21-8 from 2021. It sets out a risk-based approach tailored to an organisation's model risk profile and applies primarily to organisations above thirty billion dollars in assets. A quantum-derived portfolio allocation or risk number therefore needs the same development standards, validation, and challenge as any other model, which is the machinery described in [model risk management platform design](https://digiqt.com/blog/model-risk-management-platform-sr-11-7/).

### Why is non-determinism a validation problem?

Because a solver that gives different answers each time has to have that variability characterised.

Heuristic and stochastic optimisers, quantum and classical alike, return different solutions on repeated runs. That is acceptable in a decision process only if the distribution of outcomes is understood, bounded, and disclosed. Validation therefore has to cover repeated-run behaviour, sensitivity to input perturbation, and what happens when the solver returns a solution that violates a constraint, which is a real failure mode in approximate methods. Explaining a heuristic result to a challenge function is its own difficulty and it is not unique to quantum, as the discussion in [signal, noise, and model risk](https://digiqt.com/blog/model-risk-management-platform-sr-11-7/) sets out, and the governance parallels with newer techniques generally are covered in [generative AI and banking model risk](https://digiqt.com/blog/generative-ai-banking-model-risk/).

## Is this the same as the cryptography question?

No, and conflating them distorts both.

Post-quantum cryptography has a deadline driven by data interception today, standardised algorithms already published, and work that must happen regardless of whether quantum computing ever becomes commercially useful for optimisation. That is a mandatory programme with a defined scope, covered in [crypto-agility in banking systems](https://digiqt.com/blog/crypto-agility-banking-systems/). Quantum computing for portfolio and risk work is a discretionary research allocation with an uncertain payoff. They share a technology and nothing else, and institutions that fund them as one initiative tend to under-resource the mandatory half.

## What would a defensible programme look like?

Small, time-boxed, benchmarked, and honest about its own conclusions.

| Phase | Duration | Deliverable |
|---|---|---|
| Problem selection | 1 month | One or two problems where current answers are known to be approximate |
| Formulation | 2 to 3 months | Complete, documented constraint set, reviewed by risk and the business |
| Classical baseline | 2 months | A seriously tuned classical solution, treated as the control |
| Literature and vendor assessment | 1 month | Underlying papers reviewed, claims mapped to hardware model |
| Bounded experiment | 3 to 4 months | Like-for-like comparison including end-to-end timing |
| Decision point | Fixed date | Continue, pause, or stop, with the classical improvement banked either way |
| Watching brief | Ongoing, low cost | Defined checkpoints on hardware and algorithmic progress |

The decision point is the part that distinguishes a research programme from a permanent enthusiasm. Set it before starting, define what evidence would justify continuing, and be willing to record a negative result, since a well-run experiment that concludes the technology is not yet useful for the institution's problems is a successful experiment.

## Which metrics matter?

Improvement over the tuned classical baseline, end-to-end time, solution quality distribution, constraint violation rate, and cost per solved instance.

Report improvement against the baseline as the only headline that counts. Report end-to-end wall-clock including encoding and readout rather than kernel time. Report the distribution of solution quality across repeated runs rather than the best run observed. Report constraint violation rate, since an infeasible answer produced quickly is not an answer. And report cost per solved instance in currency, because at some point the comparison against classical compute becomes an economic one rather than a scientific one.

Quantum computing may eventually change how portfolios are optimised and how risk is simulated. It has not yet, the honest evidence says so, and the useful position for a CTO is neither dismissal nor a programme built on a vendor deck. Formulate the problems properly, tune the classical baseline, watch the field at low cost, and keep the cryptography work, which has a real deadline, entirely separate.

## Frequently Asked Questions

### Which finance problems are genuine quantum candidates?

Constrained portfolio selection, scenario and Monte Carlo style risk simulation, derivative pricing, and certain sampling and machine learning problems, all of which map onto known quantum formulations.

### Why is qubit count the wrong headline number?

Because usable capability depends on error rates, connectivity, coherence time, and error correction overhead, so raw counts say almost nothing about what a machine can actually solve.

### Why is the classical baseline the whole evaluation?

Because a quantum result only matters if it beats a well-tuned classical method on the same problem, and many published comparisons use classical baselines that were not seriously optimised.

### What questions should be asked about a vendor benchmark?

What classical solver it was compared against, how that solver was tuned, the problem size and structure, whether timing was end to end including encoding and readout, and whether it is reproducible.

### What is worth doing now regardless of hardware progress?

Formulating the problems properly, since a clean constrained formulation improves classical solver performance immediately and transfers directly if quantum hardware becomes useful.

### How does model risk management apply to quantum-derived results?

Fully. Outputs used in decisions remain subject to model risk governance, which currently means the Federal Reserve's revised guidance in SR 26-2 for institutions in its scope.

### Why is non-determinism a model validation problem?

Because a solver that returns different answers on repeated runs needs its variability characterised and bounded before its output can support a decision anyone must defend.

### How should a CTO position quantum investment?

As a small, time-boxed research allocation with defined checkpoints, kept separate from the post-quantum cryptography work, which has a genuine deadline and a different urgency.

## Sources

- [NIST, Quantum information science](https://www.nist.gov/quantum-information-science)
- [Federal Reserve, SR 26-2 Revised Guidance on Model Risk Management](https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm)

Evaluating Quantum Computing for Portfolio and Risk Simulation

Let Digiqt assess your resolution data capability, separability, and operational continuity before an authority does.

Be Ready For The Weekend You Hope Never Comes

# Building the Data and Separability a Resolution Weekend Requires

Resolution planning is the only regulatory programme designed around a scenario the institution never expects to face, which is why it so often turns into a documentation exercise. Templates are completed, playbooks are written, and the underlying question goes unanswered: if an authority took control on a Friday evening, could the bank produce a defensible valuation, identify its critical functions, and keep them running through Monday.

Those are technology questions. Recovery resolution planning technology capability is mostly about whether data exists at the right granularity on demand, whether shared platforms can be divided along legal entity lines, and whether the contracts underneath critical services survive the event. None of those is solved by a better template.

## What does resolution planning ask of technology?

Data on demand, separability of businesses, and continuity of the services that keep critical functions running.

The FSB's Key Attributes of Effective Resolution Regimes for Financial Institutions, published in its 2014 form on 15 October 2014, remains the umbrella standard for resolution regimes covering institutions that could be systemic in failure, with twelve Key Attributes and accompanying guidance including information sharing for resolution purposes and sector-specific annexes for insurers and financial market infrastructures. The technology implications flow from that: authorities cannot act on information the bank cannot produce.

### How does resolution differ from recovery?

Recovery is what the bank does itself, and resolution is what an authority does when that fails.

Recovery options assume management discretion, working systems, and time: selling a business, raising capital, reducing exposures. Resolution assumes none of that discretion, compresses the timeline drastically, and is executed by people outside the institution using whatever information and separability exist on the day. That difference should drive your engineering priorities, because capability that depends on a knowledgeable insider having a week is capability that will not be available.

### Which capabilities matter most?

On-demand data, separability, operational continuity, and contract resilience.

Those four cover almost everything an authority will probe. Everything else, including the playbooks and the governance documents, describes how those capabilities would be used. Build them in that order, because a comprehensive playbook resting on data that takes three weeks to assemble is a plan for a scenario that will not occur that way.

> **Could your bank produce a granular exposure and valuation data set over a weekend?**
>
> [Talk to Digiqt about a resolution data capability assessment](https://digiqt.com/contact-us/)

## What data must be producible on demand?

Valuation inputs, critical function mapping, exposures, deposit detail, collateral, intragroup positions, and contract inventories.

| Data set | Why it is needed | Usual obstacle |
|---|---|---|
| Valuation inputs by portfolio and entity | Establishing losses and the basis for action | Spread across systems with inconsistent granularity |
| Critical functions and the services behind them | Deciding what must continue | Mapping exists in documents, not in data |
| Exposures by counterparty and entity | Assessing contagion and netting | Aggregation logic differs between risk and finance |
| Deposit balances by protection status | Payout and transfer decisions | Insured status not held as a queryable attribute |
| Collateral positions and encumbrance | What is available and to whom | Multiple systems, manual reconciliation |
| Intragroup exposures and dependencies | Separability and loss transmission | Rarely modelled as a first-class dataset |
| Contracts including FMI and vendor terms | Continuity and termination risk | Held as documents rather than structured data |

### Why is the timeframe the hard part?

Because the requirement is hours to days, and most of this data is assembled on monthly cycles.

Every item above exists somewhere in every large bank. What does not exist is the ability to produce it consistently, at entity granularity, within the window an authority works to. The gap is almost always manual reconciliation between finance, risk, and product systems, performed by a small number of people who understand the adjustments. Removing that dependency is the actual programme, and it looks like data engineering rather than like resolution planning. Data quality across legacy estates is the underlying constraint, as set out in this guide to [improving data quality across legacy systems](https://digiqt.com/blog/legacy-skills-shortage-banking-technology/).

### What should be pre-built and what on demand?

Pre-build the definitions, lineage, and pipelines, and generate the extracts on demand.

Maintaining a permanent parallel resolution warehouse is expensive and drifts from production reality. The better pattern is to define each data set precisely, implement and test the pipeline that produces it, run it on a regular cadence to prove it works, and generate the actual extract when required. That keeps the capability live without duplicating the estate, and the regular proving run is what turns a documented specification into a demonstrated capability.

## What is separability, and why is it a technology problem?

The ability to transfer or wind down part of the group without breaking the rest, which platforms usually prevent.

Legal entity structures and platform architectures were designed at different times for different reasons, and they rarely align. A business that is legally separable frequently runs on a shared core, shares a customer data store, shares vendor licences, and shares the staff who operate all of it. That makes a paper carve-out impossible to execute in the time available.

### How do you assess whether a business can be carved out?

By testing the division against platforms, data, licences, people, and contracts.

Ask, for the business in question, whether its data can be separated cleanly or is commingled at record level, whether its applications can run independently or depend on shared platform services, whether software licences and vendor contracts permit transfer or novation, whether the people who operate it are dedicated or shared, and whether its FMI and payment access travel with it. Where the answer is no, decide whether to invest in separability or to document the constraint. This is very similar to the due diligence performed when a book of business changes hands, and the checklist thinking in run-off data readiness transfers directly.

### What does operational continuity in resolution require?

Documented intragroup service arrangements, resilient vendor contracts, and funding that survives the event.

Critical shared services must keep running when an entity enters resolution, which means the arrangements supplying them cannot depend on the failing entity's discretion or solvency. In practice that means intragroup service agreements documented with pricing and service levels rather than informal arrangements, a service company or equivalent structure where appropriate, vendor contracts that cannot be terminated because of resolution, and pre-arranged funding so the service provider continues to be paid. The controls needed to keep servicing a closed book are analogous, as described in [digital controls for run-off](https://digiqt.com/blog/financial-close-automation-banking/).

> **Could a critical vendor terminate its contract the moment resolution is declared?**
>
> [Talk to Digiqt about resolution-resilient contract review](https://digiqt.com/contact-us/)

## Why do vendor and FMI arrangements need particular attention?

Because a termination right exercised at the wrong moment stops a critical function immediately.

Review every contract behind a critical function for termination triggers linked to insolvency, resolution, credit downgrade, or change of control, and negotiate resolution-resilient terms including continuity obligations and appropriate stay provisions. Do the same for financial market infrastructure access, since membership criteria may be affected by the event that triggered resolution, and losing access to a payment system removes the ability to perform the very functions resolution is meant to preserve. Build a structured inventory of these terms rather than a document archive, because during the event somebody will need to answer which contracts are at risk within minutes.

## What about bail-in execution and liability data?

It needs liability data at instrument granularity, with holder and legal-entity attribution, produced quickly.

Executing a bail-in requires knowing precisely which liabilities exist, in which entity, under which governing law, ranked in the correct order, and held by whom to the extent that is knowable. Most banks can produce that with effort over weeks and not over days, which is the gap. Model liabilities as a first-class dataset with the attributes resolution requires, prove the pipeline periodically, and record known limitations such as holdings behind custodians rather than leaving them to be discovered under pressure.

## How do you test resolution capability?

Through dry runs measured against a resolution timeframe rather than against a reporting deadline.

| Test | What it proves | Cadence |
|---|---|---|
| Data production dry run | Data sets can be generated at required granularity in time | Annually per data set |
| Valuation drill | Valuation inputs are consistent and defensible | Annually |
| Separability desktop carve-out | Whether a business could be divided in practice | Per major business, periodically |
| Vendor and FMI continuity review | No critical service can be terminated by the event | Annually |
| Playbook walkthrough with authority | Governance, roles, and decision-making | Per supervisory cycle |
| Combined weekend simulation | End-to-end capability under time pressure | Every few years |

The dry run is the one that reveals the truth. Ask a team to produce a resolution data set within forty-eight hours without pre-warning the analysts who normally assemble it, and you will learn more about your capability than any documentation review provides.

## How does this connect to operational resilience and exit planning?

They share the same underlying assets: service mapping, dependency data, and separability.

Resolution asks whether critical functions can continue under authority control, operational resilience asks whether critical business services stay inside impact tolerances during disruption, and exit planning asks whether a provider can be replaced. All three need an accurate map of services to dependencies and honest information about substitutability, so build the mapping once and serve all three. Duplicating it produces three inconsistent versions and three sets of findings, which is a common and avoidable failure. The tolerance and mapping side is covered in [mapping critical business services and setting impact tolerances](https://digiqt.com/blog/operational-resilience-impact-tolerance/), and the provider dimension in [cloud exit and stressed exit planning](https://digiqt.com/blog/cloud-exit-plan-financial-services/). The Basel Committee's Principles for operational resilience, published in March 2021, deliberately build on existing governance, business continuity, and outsourcing expectations for the same reason.

## How should delivery be phased?

Definitions first, then pipelines, then separability, then continuity, then simulation.

| Phase | Duration | Deliverable |
|---|---|---|
| Data set definition | 2 to 3 months | Precise specifications with granularity, entity attribution, and lineage |
| Pipeline build and proving runs | 4 to 8 months | Repeatable production of each data set with timing evidence |
| Separability assessment | 3 to 5 months | Carve-out feasibility per major business, with constraints documented |
| Operational continuity | 3 to 6 months | Intragroup agreements, service structures, funding arrangements |
| Contract remediation | Ongoing | Resolution-resilient terms across critical vendors and FMI access |
| Simulation and refinement | Per cycle | Dry runs, valuation drills, weekend simulations |

Sequencing matters because separability assessment without dependency data produces opinions, and contract remediation without knowing which services are critical wastes negotiating effort on the wrong suppliers.

## Which metrics prove capability rather than compliance?

Data set production time, granularity coverage, manual intervention count, separability constraints closed, and contract remediation coverage.

Report measured production time per resolution data set against the required window, since that single number is the capability. Track granularity and entity-attribution coverage, because a data set that cannot be split by legal entity fails at the first question. Count manual interventions required in each proving run and drive it toward zero, as manual steps are what fail under pressure. Report separability constraints identified and closed per business. And measure the share of critical vendor contracts with resolution-resilient terms, which is slow-moving and highly visible to authorities.

Resolution planning is easy to treat as paperwork because the scenario feels remote. The institutions that have been through real stress describe the same lesson: the plan mattered far less than whether the data could be produced and the services could keep running, and both of those were decided years earlier by architecture rather than by planning.

## Frequently Asked Questions

### What is the difference between recovery and resolution planning?

Recovery covers actions the bank takes itself to restore viability. Resolution covers what an authority does if it fails, which means the data and separability must work without the bank's discretion.

### What does resolution planning actually demand from technology?

Data on demand at entity granularity, businesses that can be separated, continuity of shared services, and contracts that cannot be terminated because resolution occurred.

### Why is the timeframe the hardest requirement?

Because authorities need valuation and exposure data in hours or days, not in a reporting cycle. Anything requiring manual reconciliation across entities will not be available in time.

### What is separability?

The ability to transfer or wind down part of the group without breaking the rest, which depends on whether platforms, data, licences, and staff can be divided along the same lines as the legal entities.

### What is operational continuity in resolution?

Ensuring critical shared services keep running through a resolution, which requires documented intragroup service arrangements, resilient vendor contracts, and funding that survives the event.

### Why do vendor contracts matter in resolution?

Because a supplier that can terminate on insolvency or entry into resolution can stop a critical service at the worst moment, so contracts need resolution-resilient terms and stay provisions.

### How do you test resolution capability?

With dry runs against a defined timeframe: produce the data set, attempt a separability carve-out on paper, and verify that FMI access and vendor services would continue.

### What is the most common failure?

Treating it as a reporting exercise. Resolution capability is a data architecture and service-decoupling problem, and reporting templates only expose whether the underlying capability exists.

## Sources

- [FSB, Key Attributes of Effective Resolution Regimes for Financial Institutions](https://www.fsb.org/2014/10/r_141015/)
- [BCBS, Principles for operational resilience](https://www.bis.org/bcbs/publ/d516.htm)

Recovery and Resolution Planning Technology for Major Banks

Let Digiqt design supplier assessment, contract requirements, and exit testing that prove your options rather than describe them.

Due Diligence That Survives Contact With Reality

# The Supplier Assessment That Ends When the Contract Is Signed

Most technology vendor assessments in banks follow the same arc. A questionnaire goes out, comes back completed, gets reviewed, findings are logged, a risk rating is assigned, the contract is signed, and the file goes into a repository. Three years later the vendor has changed ownership, moved its hosting, added four subcontractors, and become impossible to leave, and nobody revisited any of it.

Vendor due diligence banking technology programmes are supposed to answer two questions. Can we rely on this supplier, and can we get out if we need to. The first is answered thinly and the second is usually not tested at all.

## Why does due diligence fail to protect anyone?

Because it collects assertions at a single point in time and treats collection as assurance.

The pattern is recognisable: a large questionnaire, a review that checks for completeness rather than substance, a set of findings the vendor promises to address, and no mechanism for revisiting any of it. Nothing in that process establishes that a control exists, that it operated, or that it still exists two years later. It also concentrates all the effort at the moment of least leverage for learning and the moment of most commercial pressure to proceed, since by the time due diligence runs the selection decision has usually been made.

### Why does a vendor-completed questionnaire prove so little?

Because it establishes what the vendor says, and the vendor has an incentive.

A questionnaire is a reasonable starting point for structuring a conversation and a poor basis for reliance. Its answers are self-reported, frequently completed by a sales-adjacent function, and rarely qualified. The value comes entirely from what happens next: which answers are independently verified, which are corroborated by evidence, and which are accepted as claims with that status recorded. An assessment that does not distinguish verified facts from accepted assertions is presenting both to decision-makers as though they were equivalent. Broader supplier discipline sits alongside this, as covered in vendor management strategies.

## What should due diligence depth depend on?

Criticality of the service, not the size of the invoice.

| Tier | Definition | Assessment depth | Reassessment |
|---|---|---|---|
| Critical | Failure materially disrupts a customer-facing service or a regulatory obligation | Full assessment, on-site or live evidence review, exit testing | Annual, plus on material change |
| Important | Failure degrades service or delays an obligation | Full questionnaire plus targeted verification of key controls | Every one to two years |
| Standard | Failure is inconvenient and workable around | Questionnaire, certification review, contract baseline | Every two to three years |
| Low | No access to data or systems, easily replaced | Baseline checks only | On renewal |

Contract value is the wrong axis and it is the one most estates use. A small monitoring tool with production access can matter more than an expensive commodity service, and a cheap library embedded in a payment path can matter most of all. Tier by what breaks if the supplier stops, which is the same mapping exercise that underpins [operational resilience and impact tolerances](https://digiqt.com/blog/operational-resilience-impact-tolerance/).

> **Are your supplier tiers based on dependency, or on how much you pay them?**
>
> [Talk to Digiqt about criticality-based supplier assessment](https://digiqt.com/contact-us/)

## What should be verified rather than accepted?

The claims where being wrong would change the decision.

| Vendor claim | Weak evidence | Verification that means something |
|---|---|---|
| We are certified | A certificate | The report itself, its scope, its exclusions, and its findings |
| Data is encrypted | A policy statement | Configuration evidence, key custody arrangements, who can decrypt |
| We can restore in four hours | A recovery objective in a document | Their most recent test result, including what failed |
| We patch promptly | A patching policy | Current outstanding vulnerability figures and ageing |
| Access is controlled | An access policy | The list of their staff with access to your data, and how it is reviewed |
| We do not use subcontractors | An assertion | The current sub-processor list and the notification obligation in the contract |
| Your data stays in region | A regional statement | Where support, backups, and monitoring actually run from |
| We are financially stable | A brochure | Filed accounts, ownership structure, funding position |

The last row matters more than technology teams expect. A supplier's financial position is the single best predictor of a stressed exit, and it is checkable from public filings rather than from the vendor.

### Why does a certification report need reading rather than collecting?

Because the scope statement and the exceptions carry the information.

An assurance report can be entirely clean and cover a different service, a different region, a different period, or exclude the components you depend on. Certification scope regularly omits exactly the part of the estate that matters, and a report with several qualified findings tells you more than a clean one with a narrow boundary. Read the scope, the period, the exclusions, the findings, and the management responses, and record which of your dependencies fall inside the boundary and which do not. The parts outside the boundary are the ones you still have to verify yourself.

## Which contract terms actually matter?

Audit rights, subcontracting, exit assistance, data extraction with a format, and continuity when things are going badly.

The EBA's guidelines on outsourcing arrangements, published 4 March 2019 and applicable from 30 September 2019, define outsourcing and set criteria for assessing whether a function is critical or important, which is the determination that drives most of the contractual requirements that follow. The FSB's toolkit on third-party risk management and oversight, finalised 4 December 2023, addresses identifying critical third-party services, lifecycle risk management, and the supervision of systemic dependencies and concentration.

The terms that repeatedly prove their worth: information and audit rights that extend to material subcontractors, notification and consent for subcontracting changes, a defined exit assistance period with an obligation to cooperate, data return in a specified machine-readable format with documentation, incident notification within a defined time, and service continuity obligations that survive a dispute or a termination for cause. Accountability does not transfer with the function, which is the argument made in outsourcing without outsourcing accountability.

### Why is a data extraction clause worthless without a format?

Because an obligation to return data is satisfiable in ways that leave you no better off.

A vendor can meet a bare clause with a proprietary export, an undocumented schema, no reference data, and no explanation of derived fields, and be fully compliant. Specify the format, the schema documentation, the inclusion of reference and configuration data, the medium, the timeframe, and a test right that lets you exercise extraction before you need it. The test right is the clause that converts the others from aspiration into something you can prove, and it is the one most often absent.

## How do you monitor after signature?

Continuously on a few signals, periodically on the rest, and always on change.

Ongoing monitoring should track financial health, ownership change, incidents notified and unnotified, sub-processor changes, service performance against the agreement, current assurance reports, and any concentration that has developed since the assessment. The trigger-based part matters as much as the scheduled part: a change of control, a move of hosting, a material incident, or a new subcontractor should each prompt reassessment rather than wait for the annual cycle. Vendor-delivered change into your own estate needs its own evidence discipline, which is covered in [audit-ready CI/CD evidence trails](https://digiqt.com/blog/audit-ready-ci-cd-financial/).

## What is exit testing, and why is a plan not enough?

Exit testing is executing part of the exit for real, and a plan is a description of intentions.

Almost every critical supplier arrangement in a regulated institution has an exit plan. Very few have ever had any part of that plan executed. The distinction matters because exit plans fail on specifics that only appear on contact: the export omits configuration, the identifiers are internal to the vendor and meaningless outside it, the derived fields cannot be reproduced, the history is truncated, the volume takes far longer than assumed, or the alternative provider cannot ingest what comes out. None of that is visible in a document.

| Exit test level | What it proves | Effort |
|---|---|---|
| Extraction test | Data can be exported, in what format, how completely, how quickly | Low, run annually |
| Load and reconcile test | The export can be parsed, loaded elsewhere, and reconciled to source | Medium |
| Functional replication | An alternative can reproduce the key functions with that data | High |
| Parallel operation | The alternative runs alongside for a period on real data | Very high |
| Full simulated migration | The whole exit is rehearsed end to end | Highest, for the most critical only |

Most institutions should be running the first two annually for every critical supplier, and the third at least once for the handful where dependency is greatest. The cloud-specific version of this discipline is covered in [cloud exit planning for financial services](https://digiqt.com/blog/cloud-exit-plan-financial-services/).

### Why does an untested exit plan overstate readiness?

Because it records what someone believed was possible, and belief is not evidence.

An exit plan is written by people who have not attempted the exit, using information supplied by a party with no interest in making departure easy. Every untested assumption in it is a risk carried at full value while being reported as mitigated. Running even the cheapest test, a full data extraction, typically converts several assumptions into facts and produces at least one surprise, which is exactly why it is worth doing before the circumstances are adversarial.

> **When did you last extract your data from a critical supplier and try to load it somewhere else?**
>
> [Talk to Digiqt about exit testing for critical suppliers](https://digiqt.com/contact-us/)

## What changes in a stressed exit?

Cooperation disappears, so anything depending on vendor goodwill is unavailable.

A planned exit at contract end has notice, an assistance period, and a motivated supplier. A stressed exit follows insolvency, a serious breach, a regulatory intervention, or a sudden termination, and in that scenario the vendor's staff may have left, their systems may be degraded, and their administrator's priorities are not yours. Design the exit position so the essential steps do not require them: hold your own copies of data at a useful frequency, hold documentation of the schema, understand which functions must be replaced immediately rather than eventually, and know how long you can operate without the service at all. That last number links directly to impact tolerances and to the wider question of continuity in extreme scenarios addressed in [recovery and resolution planning technology](https://digiqt.com/blog/recovery-resolution-planning-technology/).

## How do you handle concentration and downstream dependency?

Look through the supplier to what they depend on, and count exposures across the portfolio.

Two suppliers with different names running on the same infrastructure are one exposure. A dozen unrelated services all depending on a single identity provider or a single data centre region form a concentration nobody assessed, because each assessment considered one supplier at a time. Maintain a view of shared downstream dependencies across the supplier portfolio and assess them as a set, which is the analysis developed in [third-party concentration risk](https://digiqt.com/blog/third-party-concentration-risk-cloud/). Selection decisions should carry this weight from the beginning, alongside the ordinary evaluation criteria set out in a technology vendor scorecard.

## How should the programme be sequenced?

Tier the portfolio, fix the contracts at renewal, then start testing exits.

| Phase | Duration | Deliverable |
|---|---|---|
| Supplier inventory and criticality tiering | 1 to 2 months | Every technology supplier tiered by dependency, not spend |
| Assessment redesign | 1 month | Verification-based assessment, verified facts separated from accepted claims |
| Contract baseline | 1 month | Required terms by tier, including data format and exit test rights |
| Renewal-driven remediation | 12 to 24 months | Terms improved as contracts come up, prioritised by tier |
| Ongoing monitoring | 2 months to build | Financial, incident, sub-processor, and performance signals with triggers |
| Extraction testing | 3 months to start | Annual data extraction test for every critical supplier |
| Load and reconcile testing | 3 to 6 months | Proven ability to use what comes out |
| Concentration analysis | 2 months | Shared downstream dependencies across the portfolio |

Contract remediation is slow because leverage exists only at renewal, which is why the testing programme should not wait for it. Extraction can usually be tested under existing agreements, and a refusal is itself a finding worth recording.

## Which metrics matter?

Tier coverage, verification rate, exit test recency, overdue findings, and concentration exposure.

Report the proportion of suppliers assessed at the depth their tier requires. Report the verification rate, meaning how much of each critical assessment rests on verified evidence rather than accepted assertion, since that ratio is the honest measure of assurance quality. Report exit test recency per critical supplier, with anything never tested shown as never rather than as a date in a plan. Track overdue remediation findings by supplier and by age. And report the count of services sharing a single downstream dependency, because that is the number that turns several independent-looking risks into one.

Due diligence is not a file and an exit plan is not an option. The programme is worth what it can demonstrate: which claims were verified, which were accepted, and whether anyone has ever proved that leaving is possible.

## Frequently Asked Questions

### Why does vendor due diligence often fail to protect anyone?

Because it is performed once before signature, based on the vendor's own answers, and produces a file rather than a set of verified facts that anyone revisits.

### What does a questionnaire completed by the vendor actually prove?

That the vendor has a person who completes questionnaires. It establishes claims, not controls, and its value depends entirely on what gets independently verified.

### How should due diligence depth be decided?

By the criticality of the service to customer outcomes and to the institution's ability to operate, not by contract value, which correlates poorly with dependency.

### Which contract terms matter most for technology suppliers?

Audit and information rights, subcontracting notification and consent, exit assistance duration, data extraction in a specified format, and continuity of service during a stressed exit.

### Why is a data extraction clause worthless without a format?

Because a vendor can satisfy a bare obligation to return data with an undocumented dump nobody can load, which meets the contract and fails the purpose.

### What is exit testing, and why is a plan not enough?

Exit testing is executing part of the exit for real, such as extracting and loading data into an alternative. A written plan records intentions and reveals nothing about feasibility.

### What is a stressed exit and why does it change the design?

It is an exit forced by vendor failure, insolvency, or sudden termination, where cooperation cannot be assumed, so anything depending on vendor goodwill is unavailable.

### What should be measured?

Criticality coverage of assessments, verification rate versus accepted assertions, exit test recency for critical suppliers, overdue findings, and time since the last full data extraction test.

## Sources

- [FSB, Enhancing Third-party Risk Management and Oversight: A Toolkit](https://www.fsb.org/2023/12/final-report-on-enhancing-third-party-risk-management-and-oversight-a-toolkit-for-financial-institutions-and-financial-authorities/)
- [EBA, Guidelines on outsourcing arrangements](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-outsourcing-arrangements)

Posts tagged with#Risk

ALM IRRBB System Design for Interest Rate Risk in the Banking Book

Operational Resilience: Mapping Services and Impact Tolerances

Evaluating Quantum Computing for Portfolio and Risk Simulation

Recovery and Resolution Planning Technology for Major Banks

Technology Vendor Due Diligence and Exit Testing for Banks

Our Offices