When a global bank fails, the first thing that breaks is not the balance sheet. It is the data. That was the lesson of 2008, and it was learned in the most public way possible. Group entities that had shared systems, staff and infrastructure for decades were suddenly separate legal estates in separate jurisdictions, each with its own insolvency regime, its own regulator and its own claim on information that lived on servers in another country. The legal structure had always been separate. The data architecture never was. That mismatch is the cross-border data problem in its purest form, and most organizations — financial or otherwise — still have it.
The Lehman Illustration
The clearest example was the administration of the European Lehman entities. Four UK companies entered administration in September 2008 while the US operations went through a different process, and as the administrators put it, the two sides were thereafter dealt with through separate legal procedures, "as if they are no longer part of the same group". The operational consequence appears in the administrators' own progress reporting: significant early effort went into negotiating service agreements to ensure continued access to data, applications and systems, and to govern how shared infrastructure would be used and funded. Read that again. One of the largest financial institutions in the world had to negotiate for access to its own trading records, because the systems holding them belonged to an entity that was now a different party in a different country. This was not an isolated failure of one firm. It was the normal state of every multinational group at the time, and it only became visible when the group stopped functioning as a group.
Why the Regulators Rewrote the Rules
The supervisory community drew a direct conclusion. The Basel Committee's principles for risk data aggregation open with the observation that one of the most significant lessons of the crisis was that banks' IT and data architectures were inadequate to support the broad management of financial risks. The same framework contains the requirement that matters most for anyone thinking about resilience: a bank should build data architecture and IT infrastructure that supports risk aggregation and reporting "not only in normal times but also during times of stress or crisis." That phrase — not only in normal times — is the whole design brief. Architectures are tested against business as usual. They fail against entity separation, regulatory demand, provider insolvency, sanctions, and sudden restrictions on cross-border transfer. The regulatory response since then has been extensive: resolution planning and living wills, operational continuity requirements, operational resilience rules with impact tolerances, and in the EU the digital operational resilience regime, which now requires financial entities to maintain a register of every contractual arrangement with ICT providers, including the services supplied, the functions they support, data locations and subcontracting. A register of where your data is and who touches it, filed with your regulator. That is 2008's lesson turned into an annual compliance obligation.
The Failure Modes Worth Naming
Legal entity does not match system boundary. Group systems run as one estate. When an entity has to be separated — by insolvency, sale, sanctions or regulatory direction — the data cannot be cleanly split, and separation projects take years. Records sit in a jurisdiction that cannot release them. Local law, blocking statutes, banking secrecy and data protection rules can each prevent the transfer of records to a parent, an administrator or a regulator in another country. Shared services become single points of failure. One global instance of a core system means one dependency for every entity. Continuity planning that assumes the group remains intact does not survive a scenario where it does not. Nobody can produce an inventory quickly. The most common finding after any crisis event is that the organization could not say, within days, which data it held, where, under which contracts and subject to which law.
| Failure mode | Preparation proposed |
|---|---|
| Entity and system boundaries differ | Map critical data ownership and access to each legal entity |
| Records cannot cross a jurisdiction | Identify restrictions and design local retention and access |
| Shared service becomes a dependency | Test an entity separation scenario and agree continuity rights |
| Inventory cannot be produced | Maintain provider, function, location and subcontractor records |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What to Do About It
- Map data to legal entity, not just to system. For each critical dataset: which entity owns it, which entities access it, where it is stored and processed, and under whose law.
- Test a separation scenario. If one entity had to operate independently in ninety days, what would break? This exercise finds dependencies that no architecture diagram shows.
- Identify records that cannot legally cross a border. Then design for local retention and local access rather than discovering the constraint mid-crisis.
- Write continuity into contracts. Step-in rights, transitional service arrangements, escrow of data and documentation, and the right to continued access to systems if a counterparty enters insolvency. Lehman's administrators had to negotiate these after the fact; they are cheaper to agree beforehand.
- Maintain a live third-party register. Provider, service, supported function, criticality, data locations and subcontractors. Financial entities in the EU must now do this by law, and it is good practice for everyone else.
- Aggregate in normal times so you can aggregate in stressed ones. If your consolidated exposure or position reporting requires two weeks of manual work, you do not have a reporting capability — you have a reconstruction project.
- Keep the map current. A data architecture map is only useful if it reflects this quarter's reality, including new SaaS tools and AI services added since the last review.
Why This Still Matters
The scenarios have multiplied since 2008. Sanctions now force entity separation at short notice. Data localization rules restrict where records can sit. Provider concentration means a single cloud or ICT supplier failure can affect an entire market. And AI services have introduced a new class of cross-border processing that most data maps do not yet include. The common factor is unchanged. Organizations know their legal structure and they know their systems. Very few have written down how the two relate — and that document is the one you need on the day the group stops behaving like a group.
Common Questions
What did the 2008 crisis reveal about cross-border data?
That group legal structures and group system architectures were misaligned. When entities were separated by insolvency, records held in one jurisdiction became inaccessible to the entity, administrator or regulator that needed them.
What is BCBS 239?
The Basel Committee's principles for risk data aggregation and risk reporting, written in direct response to the crisis finding that bank IT and data architectures could not support risk management — particularly during stress.
What is a register of information under DORA?
An inventory that EU financial entities must maintain and submit to their regulator, covering every ICT provider contract, the functions supported, criticality, data locations and subcontracting.
How do you test cross-border data resilience?
Run a separation scenario. Ask what would break if one legal entity had to operate independently within ninety days, and check which records could not legally or practically be transferred to where they would be needed.
Audit Your Data Architecture — Outpace maps your critical data against legal entities, jurisdictions and providers, then stress-tests it against separation, insolvency and transfer-restriction scenarios before a regulator or an administrator asks.