Swiss bank UBS has opted for a centralized system for managing regulatory data, the bank’s Tony Chau said.

Chau is now executive director and lead architect in UBS’s CTO office, handling tech strategy at the bank. However, he was until recently the chief architect for UBS’s regulatory programs.

Chau says his motto then was, “Try [to] publish once to consume many times.” This is why UBS chose to build a data lake—a concept that “was fashionable a few years ago,” Chau said—where the bank could consolidate all data on transactions across all asset classes in one place.

The idea was for the front office to use the data only once before it could be fed not only into regulatory reporting platforms, but across post-trade functions such as settlement and risk systems.

“If you look at our IT costs, a lot of it is on regulatory initiatives. And we can see on the horizon more and more regulation coming to hit us. So that was the motivation in the design [of the centralized system] and behind some of these big regulatory programs,” said Chau, who was speaking at the Waters Europe conference in London on July 2.

UBS wanted to shield front-office systems from having to handle multiple similar and overlapping regulatory requirements, Chau said. While the regulators don’t necessarily ask for the exact same data, requirements can be grouped under common themes, like transparency; in other words, there is enough commonality in these requirements to make consolidating the data worthwhile.

Once UBS had all the data in a single place for Mifid II, it could then be leveraged to satisfy Swiss and Asian regulations across a range of asset classes, he said.

Imposed Improvements

Chau admitted that while regulatory standards can be onerous, they have driven better-quality data in UBS.

“Mifid II is very prescriptive in how we represent an instrument using ISIN codes [and] counterparties using legal entity identifiers. This is probably the first time at UBS that we have uniform data representation across formats—and including over-the-counter derivatives—in a timely manner and into a data lake,” he said.

Chau’s colleague, managing director Will Davis, was speaking on the same panel. Davis runs a function within compliance called “intelligence capability” that provides data to the organization for surveillance, monitoring and analytics. As such, he is a consumer of the data that Chau’s project put in the lake.

Davis said there were clear advantages to having a golden source of data like this. However, the consumers of the data within the firm need to understand where the data comes from, he said.

“What we find typically as a second-line control function is that we are going to that data lake as our primary source [information]. For example, we recently rolled out a platform for FX monitoring and it took a lot less time because we had a known, trusted data source to start working with,” Davis said.

However, he added, that doesn’t mean there is no work to do on these records before they are fit for a particular purpose.

“There are subtle differences between what is typically required for public-facing reporting versus what you are trying to do when you might want to monitor for market abuse,” he said. “I don’t think you should expect that there will always be this golden source of everything that is perfect. As part of your investment dollars, when you are implementing [data] consumption programs, you should also expect to contribute to improvements in data quality.”