Recovery and Resolution Planning Technology for Major Banks
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
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.
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.
Could a critical vendor terminate its contract the moment resolution is declared?
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, and the provider dimension in cloud exit and stressed exit planning. 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.
