Unlock the Editor’s Digest for free
Roula Khalaf, Editor of the FT, selects her favourite stories in this weekly newsletter.
HSBC and JPMorgan both have a problem with their “return to office” strategies. Having downsized their real estate footprints during the pandemic, they don’t actually have enough office space for the employees to return to.
JPM’s big campus in Columbus, Ohio, now operates a “park and ride” scheme because there isn’t enough parking if all the desks are occupied. There’s been talk of fights over ergonomic chairs. And at HSBC’s new London office, the current estimate is that there are 7,700 fewer seats than bums. Even if you can persuade the traders to crush in like battery chickens or Tube commuters, there are likely to be issues of lavatory provision and elevator capacity that will be hard to solve.
This is of course very funny. But the question of “how can you not know whether there is enough desk space before you make this sort of order?” raises another issue — one that’s actually quite important for financial regulators at the moment. When a big bank gets confused about office space it’s just annoying. If it can’t break out exposures to private credit, or to flood risk, or Russian sanctions, that’s potentially dangerous.
The problem is that while people’s mental image of bank information systems is something like this:
The reality is all too often more like this:
Basically, banks are big and complicated and changing all the time, which creates an unholy “fog of war” at the top. It’s quite a strain to get all the divisional and geographical systems to come together and produce the quarterly accounts, a further strain to produce the mandatory monthly regulatory filings, and bordering on an unreasonable ask to hope for much else. Nobody creates a large financial institution ex nihilo — they always grow, organically.
A business unit just starting out will tend to keep its own records informally, potentially even on a single spreadsheet. As it gets bigger, it might commission some bespoke software and define its own datatypes. When it gets big enough to really move the dial at a group level, people always look back and wish that everything had been integrated into the main accounting and risk management systems from day one. But, of course, that would have been a disproportionate amount of time and effort to spend on a small, startup project.
Obviously, it would be better for banks to have scalable, modular IT systems capable of handling all sorts of record-keeping requirements flexibly, automating data collection, and providing a single view of all the risks that’s customisable at will depending on the events of the day. The industry loves this idea. It loves the concept so much that many big banks will have as many as three or four such systems lying around, more or less unused after a failed integration project.
It’s called “Risk Data Aggregation and Risk Reporting” (RDARR), and right now it’s one of the biggest issues for bank supervisors. On the agenda of the ECB’s “Supervisory Reporting Conference” this week, you can see that things are being driven by a desire to reduce the burden of regular reporting and data submission. But if you’re doing that, then you need to be able to make ad hoc requests to understand issues as they arise.
Paradoxically, if the RDARR systems are more “steampunk dystopia” than “cybernetic panopticon”, measures to lighten the routine burden without compromising oversight are going to be more inconvenient and costly for the banks than just filing the same old reports.
Of course, the solution is for banks to really invest a lot of money in getting their RDARR systems up to scratch. In order to do that, they might need to get bigger and take advantage of economies of scale. That’s one reason why lots of people want to see bank mergers in Europe. But of course, it’s a lot easier to be in favour of “consolidation” in the abstract than to support an actual merger in your own back yard.
