DLT Compliance Reporting

. Today, local financial institutions are responsible for submitting compliance reporting data to the supervisory authorities. This is commonly referred to as the ‘push model’. The increasing complexity of reporting obligations often results in delayed reporting which delivers a fragmented and incomplete macroeconomic overview of the financial sector. Working with a group of nine representatives from industry and regulatory authorities, we employ the design science research methodology (DSR) in the design of an artefact, enabling the automated collection and enrichment of transactional data from DLT ledgers. Our findings demonstrate how the adoption of DLT in the financial sector will facilitate the automation of compliance reporting through a ‘pull-model’, in which regulators can access compliance data in near real-time and stage aggregate macroeconomic risk exposures for the eurozone. The findings contribute practical insights to the discourse on design-driven research on DLT and blockchain technology.


Introduction
All public and private companies operating in developed economies are subject to some level of regulatory compliance, either in the business reporting context, or through requirements for financial accounting.Due to the systemic importance of large financial institutions in the global economy, banks are amongst the most heavily regulated organizations and are subject to strict compliance reporting requirements, ranging from data gathered for the compilation of macroeconomic statistics all the way down to microeconomic supervisory needs.Since the financial crisis in 2008, regulatory reporting requirements within the EU has grown by more than 40 pieces of legislation.This has generated a significant number of new and granular reporting requirements, imposing additional pressure on both authorities' and financial institutions' reporting systems [1].
Reporting obligations are specified at the global level through supranational bodies such as the Bank for International Settlement (BIS) and the Basel Committee on Banking Supervision (BCBS) and transposed to the European level in a variety of legal frameworks.Frameworks span from the macro-level mandated by the European System of Central Banks' Integrated Reporting Framework, down to the micro-level supervision tasks mandated by EU directives and regulations that are interpreted by the European Banking Authority (EBA).These international bodies mandate prudential risk reporting through the format Implementing Technical Standards (ITS), requiring local supervisors to collect aggregated risk data from banks.ITS risk reporting comprises more than 500 complex obligations and incorporates thousands of tables containing tens of thousands of data fields.The combination of these fields is used to produce different kinds of reports, submitted to regulators on a monthly, quarterly, semi-annual, or annual basis.The annual cost of ITS risk reporting is estimated at up to €12bn annually for the population of about 5,000 banks in the European Economic Area (EEA), equivalent to approximately one third of banks' total cost of compliance (Eba 2021; EBA 2021a; European Commission 2021).In practice, it is the banks that collect data from their internal systems, map this operational data to the data elements needed to populate regulatory reports (so-called 'input data'), transforming reporting data based on reporting instructions and subsequently submitting reports to the competent authorities.Because banks are responsible for submitting this data themselves, this model is known as the push model.European banks have made moderate progress in improving data management in the push model motivated by strict obligations enforced since 2013.Yet, material challenges remain unsolved across markets, mainly due to a lack of alignment between new IT solutions and legacy systems [5].These technical challenges are exacerbated by an increasingly complex regulatory environment in which regulators frequently introduce changes to reporting frameworks and require multiple different data models for different ITS reporting requirements.As a result, banks often take up to 90 days to produce compliance reports, even under stressed conditions.This latency can have highly detrimental implications for the regulators ability to understand systemic and structural risks to the European economies.
Working with a group of nine stakeholders representing perspectives from banking, central banking, supervisory authorities, and banking regulators within the European context, we examine how the DLT-based solutions emerging between institutions and governmental bodies could reduce the reporting burden, by facilitating a so-called pull-model for compliance data, enabling regulatory bodies to pull any the necessary data as it is produced in real time.We address the research question: To what extent could the adoption of DLT based solutions optimize ITS compliance reporting for banks and organizations in the EEA?We present ongoing work towards the design of a DLT agnostic artefact designed to collect and enrich transaction data with ITS reporting compliance data.
While the discourse on the efficacy and potential of DLT in financial processes has grown at a tremendous pace in recent years, little has been said about the implications the adoption of this technology will have for the topic of compliance reporting.By employing the design science research (DSR) methodology in the design and evaluation of a conceptual artefact with this group of stakeholders at international and governmental institutions, we seek to contribute new practical and actionable insights on the topic of compliance to the growing DLT and blockchain discourse in the IS literature and beyond.
The structure of the rest this article is as follows.The compliance reporting issues regarding DLT are described in Section 2. The research approach used is presented in Section 3. Proposed artefacts are described in Section 4. Validity of the artifacts is addressed in Section 5. Section 6 and Section 7 are comprising discussion and brief conclusion respectively.

Compliance Reporting and Distributed Ledger Technology (DLT)
In the 'push-model' for compliance reporting local banks push data to their local authorities, which subsequently consolidate banking group reports and push these to the supranational level (Figure 1).The national competent authorities (NCA) for supervision, resolution (NRA) and central banking (NCB) are subsequently responsible for pushing the data forward to the respective targets at the European levelthe European Banking Authority (EBA), the European Central Bank (ECB) and the Single Resolution Board (SRB).The resolution authorities are part of the flow, as they cooperate with the other institutions, and the same reporting obligations are used when a bank is failing to assess how to resolve it.Practically, reporting is initiated by the local banks, that submit a pre-defined XML-report to the local authorities, often through a portal jointly operated by the NCB and NCA.As the reporting obligations include sensitive data related to privacy, banking regulatory secrecy and competitive status, data is masked for analytical purposes and further truncated such that sensitive data is not easily identifiable.The data is subsequently processed to create supervisory or statistical reporting, which is pushed to the European authority level as stipulated by the supranational bodies policy mandates.Traditionally, data security is managed via identity and access management controls, network segmentation, strong communication protocols supported by firewalls, data segregation, monitoring, and process controls to avoid leakage and abuse.Figure 2 shows the steps of the compliance reporting process [6].Distributed Ledger Technology (DLT) denotes a distributed transactional database that is replicated across multiple peers in a network with a shared communication protocol, facilitating a tamper-proof record of transactions [7], [8].In recent years, scholars have demonstrated how DLT may (a) enable atomic settlement of transactions [9], [10] and automate the execution of OTC derivatives [11]; (b) increase resiliency (no 'single point of failure') while reducing ambiguity in transactions by providing full disclosure of a 'single truth' for all network participants [12]; (c) simplify and automate collection, sharing, reconciliation and reporting processes for sensitive data [13] while increasing transparency and reducing operational risk [14]; and (d) promote general data protection regulation (GDPR) compliance [15].
DLT has been applied in a vast variety of use cases within and beyond the financial sector, including trading of carbon credit (green bonds) [16] in emerging economies [17] in shipping logistics and beyond [18].While the notion of permissionless blockchain technology is generally contained within the DLT classification, as a variation of the concept, in recent years the literature has differentiate the terminology.To this end, scholars now tend to use the term blockchain technology in situations where activities are conducted between unregulated counterparties.This may include the concept of 'decentralized finance' [19] or 'decentralized autonomous organizations' (DAO) [20] in which stakeholders collaborate on open-source projects through decentralized coordination [21].DLT, on the other hand, is used primarily to indicate use cases in which stakeholders are regulated and are subject to strict rules and obligations.These might include cases in which innovation is proposed in a traditional financial setting, as for the work described in this article.
While the open-source approach associated with public blockchains was initially opposed by the prevailing thinking in traditional financial services, major institutions on all continents are now experimenting with the technology in view of its attractive characteristics.As a result, banks now represent more than 30 pct of DLT use cases [22] in-line with innovation in 'machine-readable regulation' [23].Because of these unique features, the use of DLT has been studied extensively in central banking, mainly on the topic of Central Bank Digital Currencies (CBDC), specifically towards payments clearing and settlement, market compliance, asset ownership, audit trail [24] and embedded supervision and automation with smart contracts.
The traceability of DLT may reduce the risk of fraud by designing a legal framework for automating the connection of real-world identities to cryptographic identities in a common database for consumer protection, KYC rules, AML, CFT regulations tax, capital and credit management [25].This could effectively remove duplication efforts in identification across nodes and enable encrypted sharing and feedback loops between entities and regulators.Yet, traceability must be weighed against privacy and the need to keep certain information confidential.On a blockchain, where all information in the ledger is typically observed by all participants, transparency might also result in loss of privacy, confidentiality or competition issues, especially when applied to financial services.This may introduce discrepancies with data protection and applicable privacy laws, including in the EU, the GDPR, and other applicable regulations, such as local banking secrecy laws.

Methodology and Artefact Requirements
We apply the design science research (DSR) method in an iterative design, development and evaluation process [26].DSR is a research methodology widely used within the Information Systems (IS) field, but its principles has been applied in various disciplines such as engineering, education, healthcare, business, and more.It involves the creation and evaluation of "artifacts" designed to solve complex, real-world problems.Artifacts here refer to constructs, models, methods, and instantiations designed to meet specified requirements.To this end, DSR is both a problem-solving and knowledge generation process.It contributes to theory by providing a novel solution to a problem, extending our understanding of the problem space and solution design, as well as providing rigorous evaluations of these solutions.
The artefact is conceptualized through a multiple successive cycles of demonstrations and feedback-sessions with stakeholders leading into the subsequent cycles [27].We conduct evaluation processes ex-ante, through expert interviews [28] in which we attach specific emphasis on mitigation of development risk through continuous feedback [29].Our search process was initiated by a 2-day workshop with the initiating stakeholders, in which we identified and motivated the problem to define the key objectives for the artefact.We subsequently conducted a series of individual and group-based interviews with the stakeholders † , starting in January 2022.The list of stakeholders and their role(s) in the research process are shown in Table 1.The interview format was open-ended and semi-structured and they typically lasted up to 60 minutes per session.Early in the research process, we conducted stakeholder interviews without prior briefing.In the evaluation phase, we briefed stakeholders prior to the interviews, to keep them up to date on the latest iteration of the artefact design.The interviews were conducted ensuring proper consent and confidentiality, using a tailored interview guide [30].The interviews where structured to emphasize the realignment on the problem motivation, the iterative evaluation of the artefact design, and requirements for subsequent rounds.
We conducted 840 minutes of stakeholder interviews, generating 149 pages of interview notes.
The project is open-ended, and all stakeholders agreed to commit time to participate in evaluations for subsequent iterations of the artefact.While our data sampling strategy was initially aligned with our preconceptions about the use of DLT for compliance reporting, we sought to remain open to new theoretical insights in the research process [31].Through the interviews, it became clear how stakeholder incentives amplified the existing complexity in the identification and motivation of a narrow problem scope, which lead to an emphasis on the need for flexibility and modularity in the artefact design.
In parallel, we iterated on the issued experienced by reporting entities and their possible root causes.Leveraging the interviews and the global and regional large-scale studies conducted through the banking and supervision partners, this mixed approach made it clear how a lack of incentives may exacerbate the complexity of the problem.This led us to further conceptualize the need for flexibility and incentive mechanisms for the artefact.Through these focused interactions we refined the search process and literature comparison to foster a better understanding of how DLT might help reduce the compliance reporting burden, and what governance trade-offs the adoption of DLT might introduce.
This process led to the elicitation of the artefact requirements.We summarized these requirements (Table 2) grouping them into three general categories [32].

Data sources and interoperability
The artefact must demonstrate the reporting flow from reporters to authorities using a pull-model system that is interoperable with multiple other non-integrated data sources (synthetic reporting data).MRER (machine readable regulation) The system must create machine-executable versions of reporting requirements, expressed in a logical and consistent sequence useable by deterministic computing systems.

Security and Privacy
The system must ensure compliance with data privacy and confidentiality regulation, while also allowing read/write privileges to the appointed authorities as per delegated governance mandates.

Delegation
Risk and obligations must be delegated to system participants, implying the use of one entry point, a simple legally enforceable framework, with role-based access and identity management.

Accountability
Data pull vs push The system must allow the public authorities to pull the required information directly via the reporting agents for real-time analysis, supervisory review and evaluation and statistical modeling.

Relevance and Incentives
The system must feature strong incentivizes for participation, with "opt-in" mechanisms allowing phased entry for participating banks by reducing cost-ofcompliance for local banks and institutions.

Artefact Description
This early iteration of the artefact design comprises a general database architecture in which transaction events are parsed and enriched with ITS data and are subsequently stored for modular ITS report aggregation.The enriched data comprising the fields that make up ITS reports can be pulled by regulators from a data warehouse as data is consumed from the DLT environment and enriched, in near real-time.The architecture is rooted in an active node for the targeted DLT environment.The DLT node is simultaneously running an on-chain event API that listens to native transaction and smart contract events.The on-chain event API is consumed by the 'Composer', a program which observes state changes on the targeted network and records events associated with addresses registered with participating institutions.The Composer queries a database referred to as the 'ITS Datastore' to enrich the on-chain event data with ITS data and subsequently stores the fields in a data warehouse (Figure 4).The ITS datastore contains relevant information on the institutions operating on the DLT solution, which is used by the Composer in the calculation of leverage and capital ratios, liquidity requirements, credit exposures, trading flows, and more.By consuming on-chain events, the Composer maintains logs of activities on the ledger related to participating institutions, which is used in providing a picture of the bank's operational status.As illustrated above, the ITS supervisory reporting regime requires modular reporting obligations at the local level and further consolidated template reporting obligations at the national level (Figure 1).The consolidated templates are subsequently prepared for the authorities at the supranational level and are subject to comprehensive data quality checks in compliance with EBA's data point model.The artefact was designed to accommodate this process by feeding ITS data into a nested data hierarchy (Table 3), enabling the compilation of macro risk assessments and systemic risk analysis in real time, as transaction data is enriched by the Composer and stored in the data warehouse (Figure 5).The initial iteration of the artefact design was validated and tested through an early implementation, in which existing node-service providers were used to extract state changes from

Local
National Supra National a public blockchain network.By conducting transactions and deploying smart contracts designed to move assets between multiple owned accounts, we generated a small transactional dataset for testing.The transactional dataset was subsequently enriched with ITS dummy data to validate early assumptions about the feasibility of extracting and enriching DLT transaction data from live networks.
While the artefact design is intended to extract data from DLT nodes, the format can be implemented in a vast variety of use cases, extracting transactional data from legacy systems which may interface with the artefact through oracles.Data is then structured at the three reporting levels and extracted through complex queries, above.

Evaluation
While the choice of working with a broad selection of representatives from industry and regulatory backgrounds has infused the requirements elicitation process with heterogeneous perspectives on compliance, regulation, and competition, working with a 'big tent' always introduces discrepancies of opinion and priorities.As can be expected at this stage in the research process, the latest round of evaluation reveals some discrepancies in opinions of priorities, as stakeholders naturally seek to advance their mandate in the evaluation of the artefact design and future requirements.In Table 4 we feature a condensed summary of the latest round of evaluations.

Data sources and interoperability
The artefact conceptually demonstrates a pull-model reporting flow at the transactional reporting level, which can be used to aggregate reports further up in the data hierarchy.Yet, the current design fails to demonstrate how interoperability with existing legacy solutions and synthetic data sources is intended to work.

MRER (machine readable regulation)
To the extent that regulatory documents and other formal and informal legal documents are enhanced with extensive metadata fields that tell machines and human readers of the types of impacts the document will have, and that the document pertains to, and how restrictive a given document is, the artefact may incorporate machine-readable and executable reporting requirements.

Security and Privacy
The current iteration does not implement the security standards expected by industry.Future iterations will be required to meet expectations for hardened database-architecture, GDPR confidentiality, and applicable security standards such as ISO 31000/31022 and ISO/IEC 27005.

Delegation
The current iteration of the artefact inherits the properties of DLT to the extent that system participants are relieved of some obligations due to the "single-source-oftruth" available on the ledger.

Accountability
Data pull vs push The artefact demonstrates the feasibility of a "pull" approach, which can hypothetically reduce the time requires for report processing from up to T+90 days towards T+0 days.It is noted that senior management regimes prescribe that management cannot relieve their responsibilities for compliance, regardless of whether a "single source of truth" system is operational.Further work is needed to investigate how this liability regime can be adopted to a DLT system.

Relevance and Incentives
It is generally assumed that the reduction in the cost-of-compliance through automation alongside the features of DLT documented above may provide ample incentives for banks to onboard a potential solution.Yet, further work is required to understand if all elements of the ITS is suitable for automation and to which extend the artefact can be extended to integrate with legacy reporting systems.
As evident, the ongoing evaluation process reveals how IS research on DLT artefacts must be positioned to satisfy a complex web of regulatory and market-driven incentives.We believe that these findings emphasize the growing need for interdisciplinary research on the topic of DLT in industry and regulation [33].A general point of contention which continued to surface in our stakeholder interviews is the 'radical' implications for transparency introduced by the use DLT in the financial industries [34].The EU supervisory data strategy objectives aims to "modernize EU supervisory reporting and put in place a system that delivers accurate, consistent, and timely data to supervisory authorities at EU and national level, while minimizing the aggregate reporting burden for all relevant parties" [3].
Yet, it is not clear, if the radical level of transparency introduced by DLT will push this mandate too far, by exposing sensitive data to competitors, once again underlining the need for further design-oriented IS research on the benefits and limitations of DLT in industry [35].To achieve continued balance in the supervisory review and evaluation process in a system, where supervisors will gain an increased level of awareness of systemic and idiosyncratic risk due the transparent nature of DLT, additional safeguards will be required to ensure a balanced approach to implementing obligations for market disclosure without compromising EU mandates for freemarket competition.

Discussion
In this article we report ongoing progress on the design of an artefact, with a group of stakeholders representing perspectives form industry and government.The artefact demonstrates the feasibility of implementing a pull-model for compliance data, for transactions completed with DLT.We address the research question: To what extent could the adoption of DLT based solutions optimize ITS compliance reporting for banks and organizations in the EEA?
The artefact design demonstrates how authorities can query and enrich DLT transaction level reporting data and ultimately stage aggregated financial exposures without disclosing underlying individual transactions.From a supervisory perspective, pulling data directly from banks' ledgers may be perceived not only radical, but counter to tradition, because supervision, as it is practiced today, is based on consolidated data, with the intent of understanding the banks' own view of their data.Traditionally, local bank managers interpret data themselves in view of their risk appetite and tolerance, allowing for ample flexibility in the calculation of fair value or risk positions.As a result, a pull-model may be challenging to operationalize in a secretive industry, where internal control processes are commonly practiced through the '3-lines-of-defence' model and strongly relies upon the banks' own fiduciary responsibilities [36].

Limitations
The present study contains multiple limitations.Primarily, the work towards the design of the artefact was conducted in a group of nine stakeholders, led by the author team (Table 1).The group represented industrial voices, regulatory supervisors, and central bankers.Choosing stakeholders for an evaluation process in a DSR project carries certain risks, primarily: (a) Bias (b) lack of representation, and, as a consequence, (c) misalignment with the project objectives.
The selection of stakeholders clearly introduces a pro-innovation bias, primarily as the panel does not feature representatives from the traditional practical setting in which the artefact attempts to innovate.As noted above, the radical level of transparency introduced by DLT may risk exposing sensitive data to competitors.As evident, the lack of representation from partitioners in the target field of research contributes to the evaluation assigning relatively little weight to this feature of the technology.This may, in turn, introduce misalignment with the objective of understanding the extent to which the adoption of DLT-based solutions might optimize the compliance reporting burden for banks and organizations in the EEA, as the stakeholder selection features an overrepresentation of managing and supervisory parties.
Had the stakeholder group emphasized an equal weighting of practitioners, we may have seen much more push-back on the implementation of transparent infrastructure, given the potential risk these may introduce to privacy and competitiveness.
Second, an important limitation of the presented research is that it generalizes the compliance reporting process related to prudential risk, which for many regulated institutions is unique and will vary considerably, depending on the current level of automation.These inefficiencies and process flaws have been known for many years as part of supervisors' and regulators' ongoing review processes.The implied advantages of DLT, assume a general trend towards unified reporting standards in the EEA, which is currently not possible in the currently fragmented banking landscape.

Contributions
In lieu of the limitations presented above, our preliminary findings contribute actionable insights to the literature on DLT in the financial industries, emphasizing how DLT and blockchain technologies may significantly reduce the compliance reporting burden, while enabling faster processing time at a much lower cost.We extrapolate our contributions into four generalized propositions (P1-P4 below) on the impact of DLT in compliance reporting.

P1: DLT based compliance reporting will introduce a new level of precision in supervision:
The increased level of transparency enables more effective and focused supervision and more precise and faster data sharing across the regulated entities, reducing idiosyncratic and systemic risk.Issues around loss of control, cost of maintaining platform, and the risk of intrusive supervision appear more perceived than real [39].P2: Automation through DLT will reduce cost of compliance reporting and improve processing time significantly: The standardization of data taxonomies will lead to increased levels of automation and result in faster and more efficient compliance reporting, reducing cost significantly and eventually paving the way for embedded supervision [37].
P3: DLT based compliance reporting incentivizes more accurate reporting requirements: As authorities are tasked with creating their own view of banks' data there is a clear incentive for improving the reporting requirements and embrace the highly synergistic advances in machine readable regulation (MRER) [23].
P4: DLT will transform how compliance is undertaken: Moving towards a 'pull' model will challenge prevailing control practices such as the '3-lines-of-defence' model, that is widely used for compliance across industries.With increased levels of automation and smarter and more precise reporting requirements, there might be no need for a '5-lines-of-defence' model, with external auditors and authorities in addition to three internal lines of defence.Rather, inscription will evolve as the organizing principle, where the existing practices are inscribed in technological artefacts and control is dynamically negotiated [38].

Conclusions and Future Work
We investigate the implications and benefits of using DLT infrastructure for compliance reporting, as mandated by EBA's ITS regime.Through the ongoing design, implementation, and evaluation of a DSR artefact, we demonstrate the feasibility of implementing a pull-model for ITS data for transactions processed with DLT-based solutions.Working with a group of nine stakeholders from industry and government, we demonstrate how the artefact may reduce cost-of-compliance for banks and facilitate near real-time assessment of macro risks of systemic and structural nature at the supranational and national levels.We extrapolate the interim findings presented in this article into four general propositions on the implications of DLT, calling for more design-driven research on the application and limitations of DLT in industry.

Figure 1 .
Figure 1.Illustration of the Current 3-tier push-model for ITS compliance reporting

Figure 3 .
Figure 3. DSR framework applied to the project's search process

Figure 4 .
Figure 4. Artefact illustration -DLT system of systems for compliance reporting While the ITS datastore does not yet contain adequate information to enrich and submit the full scope of ITS reports at this stage in the research process, early implementations of the artefact hint

Table 1 .
Stakeholder categories and role(s) in the research process

Table 2 .
Artefact requirements for the presented iteration

Table 3 .
Embedded Data Hierarchy for Real-time ITS Reporting Aggregation

Table 4 .
Evaluation results (the latest round of evaluation)