There are literally thousands of formal risk and regulatory reports that need to be delivered to agencies around the world. Each one needs its own format, its own set of data, its own language. Without exaggerating, it is a nightmare to manage.
The regulators have no incentive to make it better – they are the masters of all they survey – so those reporting need to make their lives easier. Technology can help.
Financial institutions (including new funds & startups) face:
- thousands of risk and regulatory reports
- hundreds of jurisdictions
- hundreds of regulators
Over the last 20 years, the good decision was often to outsource much of that pain to RegTech providers to build reporting pipelines that delivered an end-to-end solution using your data.
If you are reading this in the regulatory department of a financial institution, you will know the names of the outsourced providers: AxiomSL, Bearingpoint, Wolters Kluver, Datatracks, Virtusa… the list goes on. Each of these providers will build you a tailored reporting pipeline for a specific set of regulations for a specific jurisdiction. You’ll also be familiar with the vendor lip-licking/feasting that takes place when a new set of regulations is due to come into force (see MiFID II).
Despite the promises, there are a few problems with the outsourced approach:
- Very expensive (minimum $250k per annum in licenses and $1 million in implementation)
- Brittle end-to-end pipelines (somebody else’s problem sure, but why do you think the cost is so high?)
- Limited skills retention – there goes the digital transformation dreams
This expensive and difficult dance often acts as a barrier to innovation (maybe that is why the big guys like it, but I think they too want to change). It is also a waste of in-house regulatory and technical expertise.
Content Management Comparisons
When you take a step back, the regulatory reporting problem looks very similar to the recent challenges faced by content management systems. To respond to the lack of agility in traditional architecture where the back end and the front end are tightly linked, content management has seen two major trends:
- Open-source
- Headless
Open source is less of a change (WordPress is open source and has a traditional architecture), but it has become table stakes for content management systems. Users want to be able to inspect the code and make improvements/alterations that they need for their systems. As far as your correspondent can tell, there is no open source in RegTech at all (or at least the only open source is inside the platforms and sold on with a massive premium). This is an anomaly in modern data architecture – and regulatory reporting has to start becoming a proper part of an enterprise’s data architecture.
A headless content management system is a back-end only content management system built as a content repository that makes content accessible via an API for display anywhere. The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the reports) off the “body” (the back end, i.e. the data repository). A headless system does not care about how and where your data gets delivered. It has only one focus: storing and delivering structured content and allowing people to collaborate.
Headless architecture, a natural evolution of the digital transformation technologies, is a fairly new architectural style that is gradually being adopted in most of the new technology-driven companies. Headless technology effectively means wrapping up all the business logic and functionalities in a set of APIs, which are powered by the specialized backends and make them available so that any front-end channel can hook into these APIs and provide the customer experience desired for that channel.
So when a new set of regulations comes into play, you don’t have to invent an entirely new pipeline. And you don’t get the outsourced providers licking their lips as though you are a spring lamb just coming into season.
The next generation of financial institutions are adopting ‘headless’ systems to manage their regulatory reporting needs. They want:
- A Future-Proof Tech Stack
- Front-End Flexibility
- Delivery Velocity
- Deliver Without Developers
What does a ‘headless’ system look like in RegTech
The regulatory experts and risk management teams author content in one place, while developers build a variety of presentation layers to suit the company’s — as well as the regulators’ — needs and wants.
The headless architecture contains the functionalities, rules, and processing flows required to create reporting in a programmatic way, without using cumbersome front-end technologies.
Lightweight APIs allow regulatory data stored on back-end systems to be delivered across multiple jurisdictions, and provide business rules optimized for specific regulators. In this architecture, the data is the only source on the presentation level.
Basically, you have one pool of data, which already exists, stored in the ‘headless’ system, you apply the rules provided by the individual regulator and the system extracts just that information.
Benefits of headless architecture
Delivery of new reports becomes easier and more flexible, and the launch of new products is faster. Development cost and time can be significantly reduced because of the smaller amount of web apps integrated into your legacy systems.
The financial industry needs significant change in its current business structure and data management procedures in order to comply with the regulations and market needs for a better banking experience for its customers. A headless architecture approach is designed to suit the requirements of the banking and financial industry.
TerminusDB to the rescue
TerminusDB does not give an end-to-end solution, but it provides all of the capabilities you require to build the necessary reporting and regulatory compliance.
- It is an immutable data store, so you can rewind to any report and see exactly what data was used to generate that specific report.
- You get full data lineage – see where the data came from, who interacted with it, and how it was changed
- Every single interaction, by every person is recorded in the complete commit graph. Audit requirements in a box.
- TerminusDB is a bitemporal data store, so you have a snapshot at any point in time (end of quarter) for reporting or regulatory purposes, but if you have updates to the historical data you can also go back and make changes to the data to allow more accurate analysis. Both worlds co-exist. You can replay the data used for the report and you can continue to work on the historical data.
- With regulatory data you want to be sure that the correct data is being inserted, with TerminusDB you can natively build workflows with approval steps. Once you approve the insertion, the data is merged into the store.
- Get a full knowledge graph of all your regulatory data so you can start to see what is connected. Run connection oriented queries to look for additional exposures.
- TerminusDB has a full Excel integration – so you can use Excel as your frontend or your ‘head’ – controlled end user computing
- TerminusDB is SOC2 compliant
Do you know what you knew on 15 June last year? Can you prove to the regulator that’s what you knew? What about understanding who changed the key data in your database? Most businesses really struggle to understand their data and when audits roll around they can’t easily answer important questions.
You need to be able to roll back to any time in the past and query exactly what you knew on that date. You should be able to easily take a branch of the data from that date and share with the auditor whether external or internal. You need to have a commit graph out of the box that allows you to see who changed what data when. We all know that the future is more regulation of data, more audit of data, and more understanding. You can no longer afford to not know what you know.
Open source, headless technology is the future of data architecture for financial regulations and reporting.
Try TerminusDB today.