AxiomSL
The only way to survive in the topsy-turvy world of regulation and reporting is through complete data transparency, says Ed Royan of AxiomSL
How does AxiomSL approach the challenges of data reporting?
AxiomSL started up as a data management firm, dealing with the challenge of data infrastructure, and managing a large amount of data from different sources and in different forms. Because of that, we were well positioned to facilitate regulatory reporting.
We provide one platform that can be used for a multitude of risk and regulatory reporting requirements globally. All of our investment goes in to that one platform, which is used by our client base. If, for example, one of our clients wants an improvement to the system, that request would be put in to our development cycle and, if it fits with our strategic plans, it will be incorporated in to the platform and used by all of our clients. Clients can purchase different solutions that address the regulatory requirements of the jurisdictions in which they operate, and all of the regulatory solutions have been built on the same core platform.
How do you make sure data is as accurate as possible?
Data is validated when it's loaded, when it’s read and when it’s referenced. We can highlight when this validation is broken, and when data is inconsistent or inaccurate, or not in line with the relevant rules. We validate data as it is harmonised and in the final reporting stages, and we do cross-reconciliations between reports. Clients can add internal validations too.
We also have a strong data lineage functionality, which allows clients to track and understand what has happened to their data during the preparation of their regulatory reports. Once a client has a report, they can click on a cell and look all the way back to understand exactly how that data has been transformed, and how many records and transactions have gone in to that one position. They have a transparent view of how data gets from the load stage to the report, and they can follow that process. Clients want to understand what has happened to their data, and they also want to know the rules that have been applied to it.
We don’t want to hide the transformation process. The more a client understands about our system and calculations, the more we will talk the same language, allowing us to fully support their reporting obligations. Traditional extract, transfer, load (ETL) applications put information through a transformation and give clients an output, but no one really knows what happens in the middle. Clients should be able to see the interim stages, and the rules that are applied to the data along the way.
Are you seeing more demand for that kind of transparency?
We are, and I think it is something that regulators expect too—they want firms to be in control of the reporting process. Firms might not be reporting perfect data, but regulators can accept that, as long as a firm is working towards improvements. What the regulators don’t want is a firm that doesn’t understand what they have reported, or why their data is a certain way. That is when the regulators will start to ask questions.
Regulators have a lot of information and they’re starting to apply plausibility checks, so banks really need a system that supports them in understanding what they’re doing, how they’re reporting, and how they can control it.
How do you ensure that data is not at risk?
Most of the data is held on the banks’ own infrastructures and is protected by their security policies. However, data permissions are very important.
Clients are often looking for very granular data permissions. For example, they want to ensure that some group data can be accessed by several users, but other data can only be seen by the firm that owns it. We can give certain users access to specific columns or fields within a table or we can restrict certain data, and clients can set this up based on their business entity units and their operating model.
Clients generally have our system installed on their own infrastructure, so it’s protected by the bank’s firewall. However, some banks are now looking at hosting the system outside their infrastructure, which will place more responsibility on their hosting providers.
What are the other major data challenges facing banks?
Regulation has been evolving at a fast pace, especially over the last five years. The end destination is always moving and that challenges some of the regulatory compliance architecture that banks have in place.
Firms may have a data warehouse, a reporting tool and source systems that work together well, but things are always changing, both externally, from the regulatory side, and internally, as businesses go through structural change. Firms need a system that addresses their current needs and that will continue to support them as their requirements evolve.
Clients are using our platform to help them deal with change in a more effective way, particularly as regulations continue to evolve globally.
Ed Royan is COO for Europe, the Middle East and Africa at AxiomSL
