Primary tabs

JWG Group Limited

JWG is an independent think-tank which helps financial services professionals regain control over global regulatory obligations through highly regarded research, communities, working groups and a cutting edge NLP platform.

Our experience in providing independent ‘safe space’ for large institutions to discuss RegTech and SupTech challenges is that institutions are most invested in solving the interpretation challenges inherent in their complex operational systems in order to aggregate and report accurate data to the regulator.

This is mainly larger institutions, but it is important to have representation from sell-side as well as buy-side counterparties. A feasibility study should attempt to bring together an open and collaborative effort including regulators, financial firms, industry bodies and technology firms.

We agree with the EBA’s Study of the cost of compliance with supervisory reporting requirements notes, “the topic of BCBS 239 seemed to be perceived as more relevant by large and, subject to the principle of proportionality, medium-sized institutions.”
In our decades of helping the industry run collaborative programmes, JWG has found that data collection has always proven a hot topic which gets the interest of the market.

Frankly, any scope that will increase data quality, cut costs, reduce implementation risk and create a strategic data dialogue for regulator and regulated will be popular.
We would recommend that the feasibility study look to include a reporting scope which is aligned to a business area so as to maximize the focus and participation from the many key stakeholders within the firms which will need to be involved.

One obvious business area to include in the Feasibility programme is Derivatives. Derivatives have been the subject of much RegTech/SupTech innovation and would present an ideal opportunity to harvest lessons from granular data collection efforts and understand what is required to observe the asset class from a prudential, statistical and resolution perspective.

Since 2016, the FCA, Bank of England, European Commission and other regulators have been pioneering Digital Regulatory Reporting (DRR), the use of semantic technologies to link ambiguous legal obligations to a business view of reporting data and generate test cases and code which meets the requirements.

ISDA and the FCA/ BoE TechSprint proved DRR is achievable with the Common Domain Model (CDM) in 2019. Since 2017 JWG, the independent regulatory think-tank has convened a Regulatory Reporting and Data Special (RRDS) interest group with industry SMEs. The group creates a safe space for private and public sector dialogue on a collaborative path for new reporting RegTech with open source standards.

In 2020, it was agreed that trade associations would provide an industry governance role for a JWG-provided secretariat for a global programme with a focus on the Global Derivatives Digital Regulatory Reporting Programme which could help provide input and lessons learned to the feasibility study. For more on the DRR please see the link here: https://jwg-it.eu/working-group/global-derivatives-digital-regulatory-reporting-programme/
Having analysed the EBA’s 430C data dictionary discussion in depth and discussed it with regulators, regulated financial institutions and their technology providers and trade associations, we believe it is largely complete, but could be better informed by two aspects.

There could be benefit in approaching the economy as an inherently complex system, from which one can identify two distinct dimensions in the challenges presented by data. Complexity in data reflects the extent of uncertainty and human discretion in data derivation (e.g., accounting, valuation, model risk).

Complication arises where data is constructed, through many computational steps, from many granular data elements collected from many sources. Complication grows enormously and unnecessarily when the number of sources grows (e.g. through growth and globalization) and when those sources use diverse representations of the same facts; it is added to when different judgements are applied to “correct” the discrepancies.

Two strategic levers appear for improving control of the system: complexity reduction and reduction of complication, or simplification. Complexity reduction has been sought for many years but is difficult to achieve. Indeed, improving the risk models and tuning the scope of regulation are difficult as complexity is inherent to humans and their interactions. Moreover, complexity is compounded as technology increasingly makes the system tightly coupled, on a global scale.

Simplification, reducing complication seems more easily feasible and immediately promising, should therefore be the initial strategic focus. It would also create more clarity for complexity reduction. We can achieve this through intelligent regulation of the application of technology, making it systemically safer.

An initial focus of a simplification programme could be on data standardisation and shared infrastructure (e.g. as a low hanging fruit: the LEI, fully implemented, by law, and real-time accurate – after some more work: smart contracts), where broad consensus seems achievable and action feasible, whereas benefits could accrue to all parties. Quick initial success, possible with the legal entity and product identifiers, would open the minds to more, bolder simplification. This would, in a next step, enable rules for automated compliance to be developed collaboratively and immediately increase data quality levels, reduce costs and operational risks.

The digitalization of finance will also require the sector to expand our concept of technology to include language. Indeed, once language leaves the realm of human discretion to enter the world of connected machines, rigour (mathematical clarity) and discipline (hard standardisation) become necessary for the network of machines to work well and safely.
Global, public-good data infrastructures (e.g. LEI), Common glossaries (e.g., BIRD) and agreed semantic standards for authoring rules (e.g., SBVR) should thus be treated as technology that matters for the consistency of the technology layer, and as a main source of technogenous risk (i.e. risk generated purely by the use of technology we allow in the markets).

The second aspect which we did not find in the data discussion is related to the current industry best practices and standards for semantics.

We agree with the vision of integrated glossaries and centralised obligations with agreed transformation rules at the heart of any risk information system. We did not, however agree with the analytical framework used to describe the business requirements. We have detailed our suggestions in question 6.
Not relevantSomewhat relevantRelevantHighly relevant
Training / additional staff (skills)   X
IT changes   X
Changes in processes   X
Changes needed in the context of other counterparties / third-party providers X  
Time required to find new solutions  X 
Other (please specify)X   
Highly agreeAgreeSomewhat agreeDon’t agree
Data Dictionary - Semantic level   X
Data Dictionary - Syntactic level   X
Data Dictionary - Infrastructure level  X 
Data collection - Semantic level   X
Data collection - Syntactic level  X 
Data collection - Infrastructure level  X 
Data transformation - Semantic level   X
Data transformation - Syntactic level   X
Data transformation - Infrastructure level  X 
Data exploration - Semantic level   X
Data exploration - Syntactic level   X
Data exploration - Infrastructure level  X 
In order for reporting obligations to be understood by both humans and machines, the model needs to incorporate all sources that establish reporting logic (e.g. technical standards, Q&As, industry best practices).

Each obligation which establishes the reporting logic should be clearly identified and linked to the reporting function which should be expressed in both machine readable and human readable formats.

Validated test packs are a key deliverable from digital reporting. Test packs should be created in line with the reporting model and be part of the validation of the test scenarios. In this way, the best digital reporting is created via a test-driven approach.

In our discussion with the industry about the 430C’s data proposals we noted a number of core solutions which are being implemented by the Global Derivatives Digital Regulatory Reporting programme. The top 10 are listed below and we would be happy to share more detail on them.

1. Business glossary. Create a business glossary to define unambiguous context and meaning jointly owned by regulators and the trade associations in human-readable and machine formats
2. Requirements. Specify a common approach to identifying regulatory needs (i.e., ‘the what requirements’) with a formal methodology to define requirements
3. Rule standards. Specify a standardised approach to rule sentences (i.e., the who, when, where, how, why) and transformation (e.g., C= A+B, A=C-B)
4. Data structure. Require IT to write data definitions that are composed of the data structure + regulatory business glossary definitions
5. Integration. Harmonize regulatory and industry business glossaries / metamodels across regulations with involvement of firms
6. disambiguation
7. Link glossary + DPM. Augment DPM, BIRD and other models to the business glossary via semantic anchors (URLs)
8. Industry bodies. Involve trade associations and standards bodies (e.g., ISO) to keep the business standards aligned with the business glossary (point 1)
9. Building blocks. Group data across regulations by subject area and define dependencies
10. Term dependencies. Create the plan to start with foundational glossary entries.

More context on how these technologies enable RegTech and SupTech solutions can be found in our answer to question 52 below.
The 10 solutions identified in our response would provide a platform which cuts cost massively.
JWG research shows that 65% of 17 survey respondents in Q420 viewed integrated data collection as an opportunity for efficiency. However, 35% saw this effort as part of a minimum necessary condition and mission critical mid-term for SupTech.

An integrated European reporting framework is fundamental to the fulfilment of Supervisory mandates in a digital age. Insights gained from a shared, common view of risk data across the industry will enable regulators to perform their job in the timeframes required while enabling the industry to innovate more effectively and achieve better outcomes for consumers. Please see our response to question 6 and the technology section for more context and detail.
There is an important distinction between data and business meaning which has been conflated in the paper. For machines to be able to process top down and bottom-up risk information at scale they need much more context. Therefore, the analysis of 100,000+ broad and deep ‘data points’ need to be part of a larger discussion about business meaning, data structures and requirements specification for facts and judgements. Please see our response to question 6 and the technology section for more context and detail.
The distinction between semantic and syntactic levels of a data process does not, in our view, adequately separate the concerns which should be addressed. The semantic objective in the data definitions column is focused on integrating glossaries of all reporting frameworks so that business concepts are aligned. To accomplish this objective, the dictionary needs to be linked to a business glossary. Each glossary entry should have clear and consistent grammar which enables disambiguated sentences which are machine readable to be understood in a common manner.

It is necessary to specify a common approach to identifying regulatory needs (i.e., ‘what requirements’) with a formal methodology to express needs which can then be transposed into formal machine logic. This requires a standardised approach to rule sentences (i.e., the who, when, where, how, why) and transformation obligations (e.g., C= A+B, A=C-B) which are intimately connected to the definitions of the data. SBVR is designed for this purpose.

A rigorous approach is required to define the transformations from the granular level-up (i.e., the business event, transaction, decision or judgment) to reduce confusion and simplify work.

The SBVR standard which is being incorporated into the ISO 20022 dictionary is focused on how to disambiguate the meaning in a machine-friendly manner. It is required in order to create a truly comprehensive glossary which can be leveraged by both the regulator and regulated to bridge the gap between the human, contract and technology layers.
This enables an accurate understanding of what transformations are required for granular data is critical to creating high quality information. More detail on how to specify the transformations required to avoid the well-known phenomena of ‘Garbage in, Gospel out.’
SignificantlyModeratelyLow
Understanding reporting regulationX  
Extracting data from internal systemX  
Processing data (including data reconciliation before reporting)X  
Exchanging data and monitoring regulators’ feedbackX  
Exploring regulatory dataX  
Preparing regulatory disclosure compliance.X  
Other processes of institutionsX  
Maintaining reporting obligations is a costly and time-consuming challenge which RegTech can help with. Systems change for business purposes and need to be reconciled with the previous understanding of the rules. In addition, the rules themselves change frequently and the obligation understanding needs to be kept under change control.
Important
The upfront project cost would require investment that could be paid back within 2-5 years. This quick payback is a factor of the high cost of the current system and how much lower the maintenance costs of the new system would be..
High cost reductions
other
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
Highly (1)Medium (2)Low (3)No costs (4)
Collection/compilation of the granular dataX   
Additional aggregate calculations due to feedback loops and anchor valuesX   
Costs of setting up a common set of transformations*X   
Costs of executing the common set of transformations**X   
Costs of maintaining a common set of transformationsX   
IT resourcesX   
Human resourcesX   
Complexity of the regulatory reporting requirementsX   
Data duplicationX   
Other: please specifyX   
Highly (1)Medium (2)Low (3)No benefits (4)
Reducing the number of resubmissionsX   
Less additional national reporting requestsX   
Further cross-country harmonisation and standardisationX   
Level playing field in the application of the requirementsX   
Simplification of the internal reporting processX   
Reduce data duplicationsX   
Complexity of the reporting requirementsX   
Other: please specifyX   
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
not valuable at allvaluable to a degreevaluablehighly valuable
Data definition – Involvement    
Data definition – Cost contribution    
Date collection – Involvement    
Date collection – Cost contribution    
Data transformation – Involvement    
Data transformation – Cost contribution    
Data exploration – Involvement    
Data exploration – Cost contribution    
Data dictionary – Involvement    
Data dictionary – Cost contribution    
Granularity – Involvement    
Granularity – Cost contribution    
Architectures – Involvement    
Architectures – Cost contribution    
Governance – Involvement    
Governance – Cost contribution    
Other – Involvement    
Other – Cost contribution    
  • Data definition
  • Data collection
  • Data transformation
  • Data exploration
Data definition
Please see JWG’s response to questions 6, 10 and 52 for our views on what is required.
In reviewing Figure 22 we see that low levels of semantic technology deployed in both institutions to understand the regulatory data requirements and the RegTechs to monitor regulatory feedback. This indicates to us that the new area of digital regulatory reporting is not thoroughly understood by the survey participants. The deployment of semantic technologies is a major new challenge which requires a more thorough understanding of the economic system, contracts, and the digitalisation of reporting rules. These challenges, which JWG is currently helping the industry overcome, are described in more detail in question 52 below.
From JWG’s work with leading regulators such as Francis Gross, and Gernot Stania from the European Central Bank and colleagues from the Bank of England, we believe that to effectively oversee the economy in the digital age we need RegTech and SupTech to work hand in glove to help supervisors to establish a control framework for a fast-moving system that remains effective also in extreme situations, e.g. when facing an unforeseen event unfolding globally, at high speed and in unpredictable ways across all jurisdictions of individual regulatory institutions.

A conceptual design reflection on the demands of such a control system indicates a number of specifications which the system must fulfil:
► The measurement-and-analytics chain must be automated for speed; parts of it must perform real-time, global
► Macro-pictures, analysis and simulations should be built straight-through from granular, operational data
► The same data must serve operations and measurement, by public and private parties alike
► globally standardised operational data stored in large-scale infrastructures seems a necessary, ultimate condition
► Hard standardisation through infrastructure: one fact, one representation only, accurate real time, used by all.

This set of specifications seems necessary especially in view of the crisis scenarios that are becoming possible with technology unfolding. They, however, present a fundamental, systemic design challenge that will only intensify over time: how can we reconcile the global, tightly coupled, fast, complex system enabled by technology with the fragmented landscape of institutions charged with control of that system? Add in that, to be effective, control must fulfil much more demanding specifications; it must, for instance, work at the speed and scale of the possible systemic events which are real time and global, and it must be nimble and versatile enough to adapt to surprising events as they happen.

A simple three layer model of the system appeared useful for conceptualising the problem.

The human layer, where the “economic game” between actors is played, transactions, prices, terms and agreements are negotiated, work is done, goods and services produced, exchanged and consumed.

The contract layer, where agreements among people are recorded as contracts, validated by the law of a sovereign, executed and judged when disputed by people and institutions. This layer is the actual technical substance of the economy.

The technology layer is where information is recorded and managed by connected machines and people who fill technical roles which machines cannot perform (yet). It needs to bring the human and contract layer together in a way that is observable by supervisors.

The challenge to which SupTech and RegTech must rise is to produce meaningful, timely and comprehensive insight. Reducing the complexity and complication in the system makes this challenge less insurmountable. Simplification indeed seems a necessary condition to start with.

Reporting from firms to regulators is a collaborative process which cannot be dictated by either public or private sector alone. Independent, safe space must be created between the many trade bodies, regulatory agencies, standards bodies, technology and data providers and financial institutions involved. Commitment from meaningful stakeholders, buy-in to leveraging the outputs, real deadlines, formal governance and an appropriate funding model are required to make it happen.

Together, the private sector participants must agree a model of and rules for the contract layer, the information which supervisors require from it and how they can access it. In a first step, operations subject matter experts and technologists must digitalize and elaborate existing reporting best practice to produce machine-readable test scenarios and machine executable rules.

These rules need to be linked back to the assumptions made in interpretation of the regulatory text which must be disambiguated to deconstruct the human assumptions in the language which machines are unable to deal with. At the appropriate junctures, the model needs to be shared with industry bodies and legal definition owners to validate the assumptions made in interpretation of the rules.

This deconstruction of the rule book and linkage to business rules is currently being undertaken for global derivative digital regulatory reporting (DRR) using the industry’s Common Domain Model (CDM) which is provided in an open-source model.

DRR incorporates semantic technologies to link ambiguous legal obligations to a business view of reporting data and generate test cases and code which meets the requirements. ISDA and the FCA/ BoE TechSprint proved DRR is achievable with the Common Domain Model (CDM) in 2019 and the G20 Techsprint awarded the CDM/ISDA team top prize in 2020.

In order for reporting obligations to be understood by both humans and machines, the model needs to incorporate all sources that establish reporting logic (e.g. technical standards, Q&As, industry best practices).

Each obligation which establishes the reporting logic should be clearly identified and linked to the reporting function which should be expressed in both machine readable and human readable formats.

Validated test packs are a key deliverable from digital reporting. Test packs should be created in line with the reporting model and be part of the validation of the test scenarios. In this way, the best digital reporting is created via a test-driven approach.

In our discussion with the industry about the 430C’s data proposals we noted a number of core solutions which are being implemented by the Global Derivatives Digital Regulatory Reporting programme. The top 10 are listed in our answer to question 6 (below for convenience) and we would be happy to share more detail on them.

a. 1. Business glossary. Create a business glossary to define unambiguous context and meaning jointly owned by regulators and the trade associations in human-readable and machine formats
2. Requirements. Specify a common approach to identifying regulatory needs (i.e., ‘the what requirements’) with a formal methodology to define requirements
3. Rule standards. Specify a standardised approach to rule sentences (i.e., the who, when, where, how, why) and transformation (e.g., C= A+B, A=C-B)
4. Data structure. Require IT to write data definitions that are composed of the data structure + regulatory business glossary definitions
5. Integration. Harmonize regulatory and industry business glossaries / metamodels across regulations with involvement of firms
6. disambiguation
7. Link glossary + DPM. Augment DPM, BIRD and other models to the business glossary via semantic anchors (URLs)
8. Industry bodies. Involve trade associations and standards bodies (e.g., ISO) to keep the business standards aligned with the business glossary (point 1)
9. Building blocks. Group data across regulations by subject area and define dependencies
10. Term dependencies. Create the plan to start with foundational glossary entries.

By implementing these technologies, the industry will increase data quality, cut costs, reduce implementation risk and create a strategic data dialogue for regulator and regulated.

Standardisation is needed to reduce the complication that comes from diversity in data. It is always difficult to achieve and often produces alleviation only to a problem, rather than a solution at source. Better than solving the need for standardization is avoiding the need for it by intervening at source to avoid diversity in data in the first place.

That is possible where data represents facts and where diversity in data comes from facts being represented in different ways by different sources. Where facts are represented in a unique way, offered in a single, free, public-good infrastructure (if possible, global), the need for diverse representations disappears as does the need for standardization. The Global LEI System offers that opportunity if developed accordingly. Beyond such infrastructures, standardization remains the best approach.

Standardization is required on many different levels for RegTech. Standard business glossaries are required to link the regulatory definitions of the data needs to the rules sentences which describe the transformation of that data in a common way. The reporting rules which take operational data and produce regulatory reports must then be expressed in a standard way that is able to be translated into many technical languages (or types of code). Message standards (e.g.. ISO 20022) needs to be linked to the output of the reporting rules. Finally, all of these standards need to be linked to data model standards (e.g., DPM)
PJ Di Giammarino
J