Blockchain Financial Statements: Innovating Financial Reporting, Accounting, and Liquidity Management

Abstract

The complexity and interconnection within the financial ecosystem demand innovative solutions to improve transparency, security, and efficiency in financial reporting and liquidity management, while also reducing accounting fraud. This paper presents Blockchain Financial Statements (BFS), an innovative accounting system designed to address accounting fraud, reduce data manipulation, and misrepresentation of company financial claims, by enhancing availability of the real-time and tamper-proof accounting data, underpinned by a verifiable approach to financial transactions and reporting. The primary goal of this research is to design, develop, and validate a blockchain-based accounting prototype—the BFS system—that can automate transformation of transactional data, generated by traditional business activity into comprehensive financial statements. Incorporating a Design Science Research Methodology with Domain-Driven Design, this study constructs a BFS artefact that harmonises accounting standards with blockchain technology and business orchestration. The resulting Java implementation of the BFS system demonstrates successful integration of blockchain technology into accounting practices, showing potential in real-time validation of transactions, immutable record-keeping, and enhancement of transparency and efficiency of financial reporting. The BFS framework and implementation signify an advancement in the application of blockchain technology in accounting. It offers a functional solution that enhances transparency, accuracy, and efficiency of financial transactions between banks and businesses. This research underlines the necessity for further exploration into blockchain’s potential within accounting systems, suggesting a promising direction for future innovations in tamper-evident financial reporting and liquidity management.

1. Introduction

An economic ecosystem is a complex network that consists of heterogeneous economic entities (i.e., businesses or business entities). These entities are interconnected via fundamental units of interaction—business transactions. In this complex and interdependent web of economic relationships, effective, accurate, timely, tamper-proof, and verifiable information flow is crucial to facilitate informed decision-making, creating feedback that can impact both the entities involved and the overall ecosystem. Financial statements provide a structured representation of the flow of economic activities and a current financial position report for each of these business entities. As such, they play a critical role by provisioning a decision-making tool within this economic ecosystem by systematically presenting essential financial information. This standardised format ensures clarity and uniformity in conveying vital financial data. By doing so, financial statements foster transparency and accountability and contribute to effective decision-making and the monitoring of these economic entities and the overall ecosystem.

The adoption of blockchain technology in different countries and industries encounters various challenges and is influenced by many factors. Regulatory frameworks, technological infrastructure, market dynamics, and cultural attitudes towards innovation vary widely across jurisdictions and sectors. For instance, countries with supportive regulations and tech-savvy populations may see faster adoption rates compared to those with stricter regulations and lower technological literacy. Similarly, industries with significant needs for transparency, efficiency, and security, such as finance and supply chain management, may be more open to blockchain integration. Additionally, the level of collaboration and standardisation within and across industries can greatly affect the speed and success of blockchain adoption. Understanding these challenges and factors requires a detailed understanding of the specific contexts in which blockchain solutions such as the BFS system are being implemented.

On the technological side, blockchain technology (or Distributed Ledger Technology (DLT)) has emerged as a focal point of innovation across various sectors, drawing interest from a broad spectrum of communities. The appeal of blockchain stems from its promise to provide a transparent, immutable, and cryptographically secure trail of digital events that can be shared, maintained, and verified by multiple participants and stakeholders. For example, the Bank for International Settlements [1] states that DLT adoption could fundamentally change how assets are stored and their records maintained, obligations are discharged, contracts are enforced, and risks are managed [1,2]. The potential for blockchain to streamline business processes, foster transparency, and bridge trust gaps has ignited a re-evaluation of traditional antiquated infrastructures and practices among economic actors [2,3,4,5]. Central banks and financial institutions, alongside a broader community of researchers, are exploring how blockchain could redefine intermediated manual trust mechanisms, aiming to enhance financial data management [2].

This paper investigates an economic ecosystem comprised of diverse entities interacting through transactions that form the backbone of economic activity. However, this interaction is complex due to the involvement of various individuals and institutions. While financial statements provide a structured view of an entity’s financial activities and health, they often lag behind real-time events, sometimes leading to manipulated and fraudulent reporting by entities aiming to present a more favourable financial position than what truly exists.

An extensive example of such fraud in the United Kingdom during the COVID-19 pandemic highlights the challenges faced when the UK Government launched over 150 financial support schemes to aid businesses amid economic disruptions [6]. Despite the intended relief, these efforts were compromised by fraudulent activities, with entities exploiting the system by submitting claims based on manipulated or outdated financial statements, leading to an estimated GBP 81.2 billion in fraudulent claims, as reported by HM Revenue and Customs [7,8].

The possibility of such fraud is amplified by the absence of reliable, verifiable, tamper-proof, and close-to-real-time auditability mechanisms focused on (1) a set of universally accepted verifiable authenticity controls that can guarantee the integrity and reliability of the aggregated history of accounting events, and (2) a validity mechanism to verify financial drawdown requests or monetary claims made during transactional interactions.

In response to these challenges, this paper introduces BFS. The BFS system aims to address accounting fraud and reduce data manipulation and the misrepresentation of company financial claims by enhancing the availability of real-time and tamper-proof accounting data. The research objectives focus on leveraging blockchain technology to design and develop a BFS that demonstrates the application of blockchain in creating a more reliable and verifiable financial reporting system and enabling a direct and secure channel for liquidity transmission between economic entities. This includes developing a BFS architecture that not only facilitates real-time verification of monetary claims via tamper-proof blockchain controls but also ensures post-reporting period validation to maintain financial data integrity and accuracy. This requires a complex design alignment between diverse accounting processes and blockchain technological specifications. By automating and verifying accountability and compliance with liquidity distribution rules, the BFS system seeks to enhance the reliability and timeliness of financial information flow across diverse financial landscapes. This approach not only addresses the limitations of current practices but also opens up new possibilities for more efficient and transparent financial operations.

The scope of the BFS system encompasses a detailed examination of its architectural components, the interaction mechanisms between these components, and the practical implications of its implementation. Through a proof-of-concept demonstration, this study aims to illustrate the functionality and effectiveness of the BFS system in a controlled environment. The significance of this research lies in its potential to influence the operational standards of financial systems and contribute to the ongoing discourse on the future of financial technologies. By exploring the development and impact of the BFS system, this paper lays the groundwork for further innovations in the field and invites researchers and practitioners to consider the benefits of blockchain-based solutions for financial reporting and liquidity management.

The remainder of this paper is structured as follows. In the next section, we describe the background of our research and discuss related works. In Section 3, we discuss the methodology we adopted for the research before elaborating on the BFS framework and its technological stack (Section 4). We then describe the architectural approach adopted for the BFS system, including the different domains it embraces (Section 5). Section 6 discusses the components of the BFS system, including wallets, as well as the roles within the BFS system, such as account, accountant, ledgers, financial statements, and blocks/smart contracts. In Section 7, we discuss some of the key issues raised by this work before concluding and discussing further work in Section 8.

2. Background and Related Works

In the context of financial reporting and accountability, the concept of economic entities is central, acting as the foundation for understanding and categorising various organisational structures that participate in economic activities. Economic entities are organisations or units that independently engage in economic activities, make decisions, and manage resources [9]. These entities are categorised into various types based on their roles and functions within the economy. For both central banks and non-bank entities, financial statements serve as fundamental tools for financial transparency and accountability. They provide critical information that helps stakeholders assess an entity’s performance, financial position, and future prospects [9]. In doing so, financial statements contribute to the efficient allocation of resources, the stability of the financial system, and the enhancement of investor and public confidence in the economic ecosystem. In summary, economic entities, whether central banks or non-bank entities, are integral components of the economic landscape. Their activities and the subsequent reporting on these activities through financial statements play a vital role in maintaining transparency, fostering trust, and ensuring the smooth functioning of the economy.

2.1. Accounting and Financial Statements

Accounting is a globally accepted standardised tool for accountability and reporting [9]. It involves identifying, capturing, managing, analysing, interpreting, and distributing transactional data—the economic activity of a business. Accounting records of an economic nature follow the business life cycle in the form of economic variables, principally expressed in monetary units [9]. Accounting records each elemental transaction and classifies and analyses its data with the goal of chronologically recording and periodically creating reports/financial statements [9]. These reports monitor what an economic entity does with its resources and what claims exist on the resources of the business at any point in time [9].

2.2. Blockchain

In this paper, the terms DLT and blockchain and DLT are used synonymously, despite being thematically different in terms of their underlying architectures. In the industry, it has become a common approach to combine both meanings under the same umbrella. According to [2,3], at its narrowest possible definition, “A blockchain is a special data structure-a database-that is composed of transactions, batched into blocks, that are cryptographically linked to each other to form a sequential, tamper-proof chain events that determines the ordering of transactions in the system. In this context, a transaction represents any change or modification to the database” [3]. As a broader definition of [3], ”a blockchain is a type of peer-to-peer (P2P) distributed network of independent participants that generally broadcasts all data to each other, each of whom may have different motivations and objectives. They may not necessarily trust each other, but reach a consensus (a consistent agreement about changes to the state of the shared database) on a linear history of operations of that shared database” [2,3].

In comparison to other database technologies and distributed systems, the key advantages of blockchain lie in its use of a novel data structure designed to enable bundling transactions into blocks, its ability to broadcast all data to all participants, and its automated reconciliation mechanisms, together with its resilience and transparent nature [2,3]. Some of the main components of blockchain are cryptography, P2P networks, consensus mechanisms, the ledger, validity rules, and access or permission types.

2.3. Architectural Considerations

Blockchain is a type of peer-to-peer (P2P) distributed network of independent participants that generally broadcast all data to each other, each of whom may have different motivations and objectives. They may not necessarily trust one another but reach a consensus (a consistent agreement about changes to the state of the shared database) on a linear history of operations of that shared database. On the other hand, permissioned or private refers to blockchains where access is restricted to a specific set of vetted participants. These blockchains operate in an environment where participants are already known and vetted and there is a level of trust among them. Participants are held accountable through off-chain legal contracts and agreements and are incentivised to behave honestly via the threat of legal prosecution in the case of misbehaviour. In the landscape of blockchain technologies, two significant frameworks stand out due to their distinctive approaches to security, privacy, and scalability: Bitcoin [10] and Corda [11,12,13].

Bitcoin’s Architecture. Bitcoin [10], the pioneer of blockchain technology, utilises a decentralised, peer-to-peer architecture to facilitate digital transactions without the need for a central authority. Its design is centred around the concept of a fully public ledger, which records all transactions across all network participants in a transparent and immutable manner. This ledger, or blockchain, is maintained by a consensus mechanism known as Proof of Work (PoW) [10], which requires miners to solve complex computational puzzles to validate transactions and create new blocks. Furthermore, although Bitcoin’s architecture ensures the anonymity of all participants in the network and full transparency, it does face challenges with transactional privacy. Every participant has access to the entire transaction history, which raises concerns about privacy, together with the addition of the issue of scalability. This process ensures the integrity and security of the network but also introduces challenges such as high energy consumption and scalability limitations due to the time and computational power required to process transactions.

Corda’s Architecture. Corda, on the other hand, adopts a more tailored approach, as it is designed as a permissioned blockchain platform, focusing on the needs of businesses, particularly in the financial sector [11,14]. It enables direct point-to-point messaging to guarantee private transactions, ensuring transactional data remain confidential between parties involved with verified identities, thus addressing the privacy concerns inherent in public blockchains like Bitcoin [14]. Although it is not a traditional blockchain because it does not maintain a global ledger of all transactions, it is still a DLT, enabling businesses to transact directly and privately with each other, thereby minimising unnecessary data sharing [12,14]. Instead, it allows only the parties involved in a transaction and those with a need to know to access the transaction’s details. This is achieved through the use of Corda’s “Flow Framework” for transaction processing, which facilitates direct communication between parties and complex transactional workflows [11]. Corda records transactions in individual “vaults”—“Transaction Vaults”—that are crucial for maintaining this transactional privacy while allowing traceability for compliance and transparency [11,12,13]. Furthermore, Corda’s design supports the development of “CorDapps” (Corda Distributed Applications) and the design and implementation of a wide variety of “smart contracts” that can be customised for various financial services, ensuring compliance and offering scalability and privacy [12] that the Bitcoin network cannot directly provide.

2.4. Impact of Blockchain on Accounting

Blockchain technology is increasingly recognised as a transformative force in accounting and business operations, with research indicating its potential to enhance transparency and security in financial transactions. Blockchain innovation has the potential to enhance legacy infrastructures [2,15] that surround economic activities by creating new and improved blockchain-based business models, which, in itself, is believed to be one of the major factors behind the push for DLT adoption by industry [2,15]. This will allow for a fundamentally different way of conducting and tracking financial transactions and could thus challenge the centralised nature of existing financial systems, starting with central banks [2,15] and extending to diverse participants in the economy.

Blockchain-based accounting is gaining increasing attention from both industry and academia [16,17,18,19]. According to [16], accounting has emerged as a significant sector standing to benefit from the adoption of blockchain technology. The inherent immutability feature of blockchain is expected to facilitate the tamper-proof creation and maintenance of permanent and timely records of transactional data [19], thus enhancing the reliability of record-keeping. This attribute of blockchain also offers network participants a robust capability for detecting any manipulation or alteration of recorded transactional data [20], thus discouraging improper accounting practices and transactional data manipulation and mitigating fraud [20,21]. The immutability and decentralisation of transparency [22] afforded by blockchain presents opportunities for verifiable data access and sharing, close-to-real-time reporting, and transactional history verification. Improved transparency minimises data asymmetry between stakeholders [22,23]. These aspects promote the advancement of the integrity and reliability of accounting processes and offer the establishment of more secure and transparent blockchain-underpinned accounting controls to counteract the likelihood of unethical conduct [16].

Studies such as those by [24,25] look into how blockchain can secure data transmission in reporting and auditing processes. They highlight the importance of cryptography in strengthening the trustworthiness of financial information [26]. Emerging research also points to the role of blockchain in reshaping future decision-making processes by integrating advanced technologies like AI and Big Data analytics. As reported in [2], relevant business processes related to current Big Data analytics and the importance of filtering and signal extraction utilised by industry are growing [27,28,29]. The opportunity here is to improve the current limitations in the transaction processing life cycle, such as problems related to the quality and completeness of messaging between systems, the lack of reference data systems, various problems with bookkeeping, and manual or even paper-based confirmations [30]. This integration could revolutionise the accounting profession, altering the traditional roles of accountants and auditors, as identified in [26,31].

Lastly, the effectiveness of blockchain in fraud detection has been studied across various business domains, including insurance, banking, and real estate. The literature on the application of blockchain technology to mitigating accounting fraud reveals a consensus that blockchain provides a secure and transparent platform that various stakeholders can trust to prevent fraudulent activity [32].

Rückeshäuser, N. [16] identifies one of the core problems with existing accounting practices as the ability to conduct fraud through the use of accounting manipulation and concealment techniques. The author defines accounting fraud as the deliberate preparation and dissemination of accounting records through the direct or indirect involvement of the top management of an organisation. Traditional accounting systems rely heavily on centralised authority and are susceptible to the risk of management override—a significant existing concern in accounting fraud. The author of [16] concludes that DLT ensures that transactions are not unilaterally recorded or altered without consensus, thereby offering structural resistance to fraudulent activities. The same study also states that blockchain-based accounting systems could enable decentralised consensus mechanisms, which may act as a barrier against the manipulation of financial data.

The role of blockchain in accounting is also viewed through the lens of it being a foundational technology rather than a disruptive one, with the potential to fundamentally transform economic and social systems [26]. Blockchain’s decentralised and immutable ledger offers a reliable framework for transparent and reliable transactions and is visible to all network participants, which is key to deterring potential manipulative actions [26,33]. Moreover, blockchain’s attribute of immutability can significantly aid in fraud detection since once data are recorded on the blockchain, the data cannot be altered or deleted, thereby creating a verifiable and permanent record of transactions [33].

Mingming, T. [34] offers more relevant insights into the transformative role that blockchain can play in modernising Accounting Information Systems (AISs). The work emphasises the importance of the integration of blockchain technology into existing accounting frameworks to enable improvements in the auditing process, making it more efficient and less prone to errors. The same study states that the inherent characteristics of DLT, such as the immutability of records and transparency of transactions, make it an excellent tool for building robust accounting information systems, aligning with the core requirements of reliable financial reporting and fraud prevention. By ensuring that financial entries cannot be tampered with post-confirmation, blockchain creates an environment where fraud is not only difficult to commit but also easier to detect [34]. One of the revolutionary aspects of blockchain in AISs, as highlighted in [34], is the potential for real-time auditing. This can ensure that anomalies are quickly identified and addressed, thereby maintaining the system’s integrity.

Bonsón, E. et al. [23] explore the implications of blockchain for auditing and accounting within the context of the emerging digital economy by evaluating how blockchain can strengthen the trustworthiness of financial statements and reduce the occurrence of accounting fraud. The theoretical insights in [23] underscore the transformative potential of blockchain in accounting and auditing, advocating for a future where financial reporting is more secure, transparent, and efficient. The findings in [23] provide a tangible model for the application of blockchain in combating accounting fraud. The research is predicated on the following:

• A permanent and unalterable record of all transactions provided by the blockchain ledger that safeguards against fraudulent alterations [23];
• Decentralisation, eliminating the potential for a single point of failure or control, which is often exploited in a fraudulent scheme [23];
• Blockchain transactions being transparent and verifiable by any allowed participant in the network, validating the accuracy of financial information [23];
• Blockchain-based smart contracts being able to automate and enforce compliance with accounting standards and policies [23];
• The real-time and comprehensive nature of blockchain records being able to streamline the auditing process, making it more efficient and less susceptible to human error or intentional oversight [23].

However, blockchain’s advantages in fraud prevention are balanced by challenges related to scalability, energy consumption, regulatory uncertainty, and the permanence of its records [33]. There is a recognised need for accounting professionals, especially forensic accountants, to adapt and develop technical skills suitable for detecting fraud within blockchain systems, as traditional methods may not suffice [26]. These forensic accountants, for instance, face the task of navigating through vast and complex databases to detect patterns of fraud. Blockchain’s distributed data organisation can pose both opportunities and challenges in this regard [35]. Additionally, [16] notes the concerns surrounding the adaptation of existing legal frameworks, the technical complexity of blockchain systems, and the need for widespread understanding and trust in its mechanisms. These studies suggest that while blockchain can play a significant role in mitigating fraud, there is still much to be explored, particularly in terms of practical applications, regulatory responses, and the integration of this technology with existing financial systems [5].

Despite increasing research on blockchain applications in accounting, there is still a need for a complete framework that integrates blockchain technology with traditional accounting systems to enhance financial reporting and liquidity management [5]. Previous studies have primarily focused on the general benefits and challenges of blockchain in accounting, such as increased transparency, immutability, and energy efficiency. However, specific problems in existing accounting systems, such as privacy concerns, scalability issues, and regulatory compliance, have not been fully addressed. The BFS framework proposed in this paper aims to address this gap by using the unique features of two distinct blockchain architectures—Bitcoin and Corda—to create a hybrid solution for these specific challenges. The dual-blockchain approach of the BFS framework ensures privacy and confidentiality by incorporating Corda’s privacy-oriented architecture, which allows sensitive financial information to be shared only among relevant parties. Additionally, the framework uses Corda’s scalability features, such as its ability to handle complex transactions and support off-chain processing, to improve the efficiency of financial reporting and liquidity management processes. The BFS framework integrates smart contracts and automated compliance mechanisms to ensure that financial transactions adhere to regulatory requirements and accounting standards, reducing the risk of fraud and errors. By combining the strengths of both the Bitcoin and Corda architectures, the BFS framework offers a solution that enhances the overall performance and security of accounting systems, distinguishing it from existing approaches in the literature.

3. Research Methodology

The Design Science Research Methodology (DSRM) is central to merging design creativity with scientific investigation, targeting the development of innovative technological solutions tailored to practical requirements within their application contexts. The BFS architecture is designed, developed, and refined through a fusion of the DSRM guidelines by Wieringa, R.J. [36], Peffers, K. et al. [37], and Geerts, G.L. [38], ensuring that the design not only meets theoretical standards but also effectively addresses real-world needs.

• Wieringa, R.J. [36] focuses on providing guidelines on how information systems and software engineering research can be performed by iterating through activities of designing and refining a technological artefact that improves something for stakeholders.
• Peffers, K et al. [37] communicates a nominal process model for DSRM execution and the mental model for such a research presentation and evaluation.
• Geerts, G.L. [38] illustrates the application and integration of DSRM to Accounting Information System (AIS) research through retroactive analysis.

The rationale for selecting DSRM over other methodologies is multi-faceted and is driven by its problem-solving investigative and exploratory nature, involving a structured and creative process of designing, building, and evaluating artefacts while ensuring a practical and iterative development approach [36]. To successfully utilise DSRM for the design of the BFS architecture, the development of its artefact and the demonstration of the integration of blockchain architectural components into the accounting domain, this paper starts with a clear definition and understanding of the major concepts of this methodology, which are as follows:

• The object of its study, which consists of the artefact itself, the contexts, and the interaction within its problem;
• The primary activities, which consist of the design of the artefact to improve the problem context and the investigation of the knowledge about this artefact in its context [36].

The ultimate goal of this paper is to explain and predict the overall utility of the BFS system through its architectural insights, aiming to enhance the efficiency and transparency of financial reporting in the digital age. According to Wieringa, R.J. [36], it is essential to start by clearly defining an “object” to guide a clear understanding of the scope, depth, and direction of the research work. The object often becomes the tangible output of the research process [36,38]. The definition of the object encapsulates several key components:

• The artefact (the Blockchain Financial Statements (BFS));
• The context (financial reporting and liquidity management);
• The interactions (transactional exchanges among various economic entities and involving BFS).

3.1. The Artefact

In DSRM, an artefact refers to a construct developed to address a specific problem and embodies the practical application of theoretical concepts [36]. Within the setting of this paper, the object of this study is the exploration and development of the Blockchain Financial Statement (BFS) as the innovative artefact that integrates blockchain technology with financial accounting processes. This artefact represents a novel combination of two patterns of different blockchain architectures and the integration of this technology into a financial accounting system with the aim of addressing the issues of the authenticity and integrity of post-accounting monetary claims. The primary role and purpose of the BFS system’s functionality are to provide a solution to the problems of tampering within financial reporting, borne out of inadequate auditability processes. It is designed to facilitate an on-demand authenticity mechanism for the validation of these post-reporting period monetary claims. The guarantees provided by the BFS system are supported by the maintenance of a tamper-evident blockchain ledger that contains the financial statements of an entity.

3.2. The Context

In DSRM, the context for the artefact centres around the critical definition of its operational environment—the settings or conditions in which this artefact is applied and holds relevance, or the specific domain it impacts [36], citepaper1. This research project is contextualised within the domain of financial reporting and liquidity management. This domain is characterised by the risks of intentional fraudulent reporting in financial statements, necessitating a reliable, verifiable, and tamper-evident mechanism for auditability. In response to these challenges, the innovation of the BFS system is to provide a secure and transparent framework for reporting the outcomes of business transactions. This role is increasingly vital, given the evolving landscape and increasing digitisation of financial interactions, where traditional mechanisms fall short in addressing new complexities. The development of such a solution targets the enhancement of financial reporting mechanisms, especially focusing on liquidity management among a range of economic entities. It ensures that the BFS system is relevant and highly applicable to the real-world environment and that it improves business processes in the economy.

3.3. The Interactions

According to Wieringa [36], “the design science researcher designs not just an artefact, but also designs a desired interaction between the artefact and the problem context”. Exploring interactions between the BFS system and its contextual ecosystem of distinct economic entities is important, as these combine diverse and dynamic relationships and activities that could transpire between the BFS system and its users. In this research, these interactions are illustrated through transactional exchanges between economic entities and the coordination of responsibilities among them [38]. These hypothetical stakeholders interact with the BFS system in various capacities, such as incorporating a business, conducting transactions, performing reconciliation, and generating reports. The exploration of interactions is descriptive and also serves several important functions:

• Demonstrating Practical Applicability: The interactions provide evidence of how the BFS system can be implemented and utilised in real-world financial settings, thus bridging the gap between theoretical development and future practical deployment.
• Assessing the System’s Efficacy: Through these interactions, this research assesses the artefact’s effectiveness in facilitating transparent and secure transactions.
• Understanding the Impact: By studying these interactions, this research gains insights into the system’s impact on routine business operations and its role in enhancing the overall quality of financial reporting.
• Identifying Opportunities for Improvement: These interactions also serve as a feedback mechanism, highlighting areas where the BFS system can be further refined to better meet the needs of its potential users.

3.4. The Design and Investigation

This step focuses on creating the BFS system itself and involves conceptualising, constructing, and iterating the design. Initially, the conceptual architectural framework of the BFS system is developed. This includes defining how the dual-blockchain architecture can interact with accounting and transactional processes. Next, detailed descriptions of the design components and key data structures of the BFS system are presented, such as smart contracts for automating accounting and transactional processes and the integration of the Bitcoin and Corda architectures adopted in the BFS system to fulfil its specific functionalities. The BFS system undergoes several iterative design and development cycles. Each iteration involves building a prototype and testing, analysing, and refining the design.

Theoretical and practical knowledge of Domain-Driven Design (DDD) is essential for modelling the BFS system to ensure its functionality is directly relevant to the needs of its users. Familiarity with iterative design and development methodologies, as well as versioning control, ensures that the BFS system can be developed and refined in a responsive and adaptive manner. Understanding DSRM principles to guide the BFS system’s development process ensures that each design iteration contributes to the artefact’s functional utility.

4. BFS Technological Stack—Dual-Blockchain Framework

The BFS system operates within an economic ecosystem characterised by a complex network of diverse business entities interconnected through business transactions. These transactions, essential for transferring monetary value through digital funds or tokenised assets, occur across the BFS ecosystem via wallet addresses, impacting each entity’s monetary stance. The BFS system’s technological framework introduces a novel dual-blockchain architecture, uniquely merging the distinct architectural elements of Bitcoin and Corda. This design not only automates the execution of transactions and accounting processes through innovative business and accounting transaction smart contracts but also standardises and automates the capture and integration of economic activities into a cryptographically verifiable accounting record for each entity. Moreover, the dual-blockchain setup enables the BFS system to operate effectively in a multi-blockchain environment, addressing critical trade-offs between accountability and privacy while securely sharing sensitive financial information. This ensures that the BFS architecture supports robust financial reporting while upholding the confidentiality and integrity of the data and participant privacy.

First, the traditional “Bitcoin” [10] blockchain framework is adapted to design and implement the BFS filing history data structure utilised to store the financial statements of an entity (see Figure 1). This decision is motivated by the guarantee of this data structure to maintain a verifiable, tamper-proof, and cryptographically linked chronology of events within it. The BFS system is designed to handle the transformation of raw economic data into a format suitable for financial reporting, as follows:

• Economic data generated from completed business transactions are transformed into accounting data, anonymized, classified, aggregated, and then packaged into financial statement reports.
• These reports are stored in a traditional chain of cryptographically linked blocks within a permissioned blockchain data structure—the filing history.
• This separate filing history blockchain is owned and distributed among the members of entities, such as business owners, accountants, employees, and so on.
• Additionally, access permissions to this ledger can be modified and extended to qualified external stakeholders, such as other controlling entities (e.g., shareholders), or government bodies for regulatory or tax purposes.

Serving as a filing history, this blockchain ledger is utilised as a tamper-proof financial reporting tool for documenting the financial health and trajectory of the business. However, in the traditional Bitcoin blockchain architecture, every peer participating in the network receives and processes every transaction ever conducted. Despite Bitcoin’s architecture being known for ensuring participant anonymity, its broadcast communication method raises ongoing concerns regarding the privacy of business-sensitive transactional data.

To address the critical challenge of ensuring transactional privacy while providing traceability for compliance or validation and transparency, the BFS system’s design incorporates specific components of the Corda architecture [11], such as the point-to-point messaging of Corda’s Flow Framework [11], and business transaction registers inspired by Corda’s Transaction Volts [11]. These components are illustrated in Figure 2.

• Corda’s Flow Framework [11] ensures that sensitive transactional data are only transmitted between the parties relevant to the transaction, thereby remaining confidential between them and safeguarding business-sensitive information.
• Corda’s Transaction Volt [11] is implemented as a business transaction register for each BFS entity. It serves as an application-local off-ledger repository that stores all business transactions (see Figure 2) in their “raw state”, untransformed and ready for accounting processing and future validation if requested.

This novel BFS framework merges the immutable and transparent characteristics of a Bitcoin-inspired permissioned blockchain, utilised for publishing financial statements and serving as a data repository, with the privacy and transactional efficiency provided by Corda’s DLT. In the BFS architecture, point-to-point messaging allows information to be exchanged directly between parties involved in a transaction, bypassing the need for broadcasting sensitive data across the whole network. Meanwhile, the business transaction registers provide a secure and organised method for recording and tracking each transaction through an internal traceable link (transaction hash, together with cryptographic identifiers of transacting counterparties), supporting robust audit and compliance processes. This combination represents a strategic tailoring of blockchain technology to enhance privacy while preserving accountability, transparency, and efficiency in financial reporting and management. Through this dual-framework approach, the BFS architecture and its Java implementation demonstrate the system’s capability to function effectively within a complex, multi-blockchain environment, providing a foundational model for innovative liquidity management and reporting practices.

4.1. Conceptual Decisions vs. Implementation Details

The BFS system conceptually requires a dual-blockchain framework to address the need for both transparency and privacy in financial reporting. This is necessary for ensuring public verifiability and auditability of financial statements while maintaining the privacy and security of sensitive transactional data. The conceptual basis for the design, inspired by a dual-blockchain architecture, aims to ensure the data integrity of publicly available financial statements and facilitate the transactional privacy of business-sensitive information through point-to-point broadcast. This concept is not inherently tied to Bitcoin and Corda but rather to the need for combining public and permissioned blockchain systems. The BFS architecture leverages both Bitcoin and Corda blockchain components to achieve a balance between data integrity, transparency, and privacy. While Bitcoin and Corda were selected for their strengths in these areas, other blockchain technologies could potentially be used to implement the BFS framework. The critical requirement is to have one public blockchain system for transparency and another permissioned blockchain system for privacy.

The specific choice of Bitcoin for the public blockchain and Corda for the permissioned blockchain is an implementation detail. The BFS system uses Bitcoin’s UTXO (Unspent Transaction Output) model for its public blockchain component. This choice is based on Bitcoin’s proven security and widespread adoption, which ensures the immutability and public accessibility of financial data. The public nature of Bitcoin is specifically leveraged for the publication and dissemination of publicly available end-of-accounting-period financial statements, such as balance sheets. For the permissioned blockchain component, BFS uses Corda’s Transaction Vault model. Corda is chosen for its design, which emphasises privacy and the ability to handle complex transactions securely among known parties. The private, point-to-point nature of Corda is necessary for the privacy of sensitive transactional data shared only between the counterparties of the transaction.

4.2. Data Model

Bitcoin: The BFS system leverages a modified version of Bitcoin’s Unspent Transaction Output (UTXO) model, adapted to implement an accounting data-based “funds verification consensus” model. This adaptation validates monetary claims made by business entities during transactions, ensuring that funds are available and legitimate before any transfer is approved. Corda: In a permissioned setting, BFS employs Corda’s Transaction Vault model. Each business transaction is recorded in the application-local off-ledger repository of the involved entities. This design ensures that transaction data remain private and secure, accessible only to the authorised parties involved in the transaction.

4.3. Query Processing

Bitcoin: Queries in Bitcoin are processed using blockchain explorer tools. These tools provide public access to the history of financial statements, enabling transparent auditability and traceability of all recorded and reported economic activity of a business. Corda: Queries are handled through its vault, which maintains a privacy-preserving mechanism to access transaction records. This allows entities to verify and audit transactions while keeping sensitive data secure and inaccessible to unauthorised parties.

4.4. Adaptation of Bitcoin and Corda Concepts in BFS

The BFS architecture uses concepts from both Bitcoin and Corda blockchains, adapting and combining elements from each to create a novel dual-blockchain framework tailored for financial reporting and liquidity management. While inspired by Bitcoin’s block structure for its filing history chain, the BFS system does not directly implement Bitcoin’s proof-of-work consensus mechanism. Instead, it uses a custom “funds verification consensus” approach more suitable for financial validation. This consensus mechanism verifies the economic validity of transactions by comparing transaction values against available funds in the latest accounting records, ensuring sufficient funds exist without revealing sensitive details. From Corda, BFS adapts the concept of point-to-point messaging and transaction vaults, modifying these to fit the specific needs of secure, private financial transactions within the BFS ecosystem. Specifically, BFS implements a “business transactions register” inspired by Corda’s Transaction Vault, serving as an off-ledger repository for transaction records. These adaptations allow the BFS system to balance the transparency requirements of financial reporting with the privacy needs of business transactions. The resulting hybrid architecture enables the BFS system to implement its unique features such as the integration of accounting processes with blockchain technology while addressing the specific challenges of financial reporting and liquidity management in ways that neither Bitcoin nor Corda could achieve independently.

5. Use Case

In this paper, we describe the key components of the novel Blockchain Financial Statement (BFS) architecture and its partial Java implementation within the domain of accounting. The BFS system is designed to facilitate and document various business and accounting transactions among business entities, providing a robust framework for financial reporting, accounting, and liquidity management. The BFS system leverages blockchain architectural components to ensure the privacy of transactional data and the integrity, transparency, and accuracy of accounting data, thus enabling secure, tamper-proof interactions between economic entities within a multi-blockchain ecosystem.

Figure 3 illustrates the sequential steps of the BFS use case. Consider a scenario involving three business entities: Entity A, Entity B, and Entity C. Entity A is incorporated as a private company limited by shares, with Entity B as its parent company and sole shareholder. Entity A needs to purchase commercial paper from Entity C but lacks the necessary Treasury bills for the transaction. Entity B, holding the required Treasury bills, lends them to Entity A, which then uses them to complete the purchase from Entity C. All these transactions and corresponding accounting records are securely managed and recorded within the BFS framework, demonstrating its practical application in real-world financial operations.

In summary, the BFS system is designed to provide a robust, efficient, and transparent framework for financial reporting and liquidity management, addressing key challenges in the traditional financial ecosystem through the innovative use of blockchain technology. This use case illustrates how the BFS system can be used to facilitate and document various business and accounting transactions among businesses, demonstrating its application in financial reporting, accounting, and liquidity management.

5.1. Use-Case Participants

The roles within each entity are defined to manage operations, financial reporting, and interactions with other entities, highlighting the comprehensive capabilities of the BFS system. The use-case participants are defined as follows:

• Entity A is a newly incorporated private company limited by shares, which acts as the central business entity in this use case. The roles within Entity A are designed to manage its operations, financial reporting, and interactions with other entities. Its roles are as follows:
  • Two director wallets—These wallets are managed by the directors of Entity A. They are responsible for overseeing the overall operations of the company, making strategic decisions, and authorising significant transactions, such as share issuance and sales.
  • One accountant wallet—This wallet is managed by the accountant of Entity A. The accountant is responsible for maintaining the company’s financial records, executing accounting transactions, generating financial statements, and ensuring compliance with regulatory requirements.
  • One borrower wallet—This wallet is managed by an employee or an authorised representative and facilitates borrowing activities for Entity A. It is used to request and manage funds borrowed from other entities, such as parent companies or financial institutions.
  • One employee wallet—This wallet is managed by an employee of Entity A. It is used to execute day-to-day business transactions, such as purchasing assets, paying suppliers, and other operational activities.
• Entity B is the parent company of Entity A and holds 100% of its shares at incorporation. Entity B plays a crucial role in providing financial support and overseeing the operations of Entity A. Its roles are as follows:
  • One shareholder wallet—This is managed by Entity B and represents the ownership stake in Entity A. It is used to hold and manage the shares issued by Entity A, participate in shareholder decisions, and receive dividends or other shareholder benefits.
  • One lender wallet—This wallet is used by Entity B to lend funds or assets, such as Treasury bills, to Entity A. It facilitates inter-company lending and supports the financial needs of Entity A for its business operations.
• Entity C is an external business entity that interacts with Entity A in business transactions, such as buying and selling financial instruments. Its role is as follows:
  • One counterparty wallet—This wallet is managed by Entity C and is used to engage in transactions with Entity A. In this use case, it is specifically used to sell commercial paper to Entity A in exchange for Treasury bills. The wallet ensures secure and verifiable transactions between Entity C and its counterparties.

5.2. Step-by-Step Use-Case Implementation

This scenario illustrates how the BFS system can be used to facilitate and document various business and accounting transactions among these entities, demonstrating the BFS system’s application in financial reporting, accounting, and liquidity management. The steps of this implementation are as follows:

• Entity A Incorporation:
  Scenario: Entity A is incorporated as a private company limited by shares.
  Implementation: The BFS system that belongs to Entity A is instantiated and contains the “filing history chain of blocks”, a data structure inspired by the Bitcoin data structure [10]; the integrity of the data within the blocks is guaranteed by the integrity of the ledger itself [2]. In our proposed architecture, the BFS system records the incorporation details of Entity A, including the Certificate of Incorporation, in the genesis block of Entity A’s BFS filing history blockchain, as illustrated in Figure 1. This block is uniquely identified by its hash, ensuring the integrity and authenticity of Entity A’s foundational data.
• Business Transaction 1—Share Purchase:
  Scenario: Entity B, as the parent of Entity A, purchases shares from Entity A and becomes the sole shareholder at incorporation.
  Implementation: The BFS system documents the shareholding structure, linking Entity B’s wallet to Entity A’s blockchain, as illustrated in Figure 4 and described further. The BFS system processes this transaction using a BFS business transaction smart contract and tokenised shares in accordance with Corda’s Flow Framework [11], which provides point-to-point data broadcast only to the counterparties of the business transaction. The BFS business transaction smart contract automates the transfer of share certificate tokens from Entity A’s ownership through Entity A’s director wallet to Entity B’s shareholder wallet in exchange for digital funds that are simultaneously transferred from Entity B to Entity A. The successfully completed transaction is then recorded in the business transaction registers of Entity A’s BFS and Entity B’s BFS, respectively, in accordance with Corda’s Transaction Vault [11]. This flow is illustrated in Figure 2.
• First Accounting Transaction:
  Scenario: Entity A records its first accounting transaction related to the share purchase.
  Implementation: The accountant of Entity A initiates the first accounting transaction smart contract, which automates the BFS accounting cycle; this is illustrated in Figure 5. BFS accounting smart contracts transform economic data generated by the first business transaction into accounting data and post this accounting data into the accounting journals and ledgers of the BFS system that belongs to Entity A. Final financial statements are automatically generated and appended to the BFS filing history blockchain, ensuring the accuracy and transparency of Entity A’s financial reporting data. These final financial statements are published in the Bitcoin-inspired data structure of Entity A’s BFS filing history block, as illustrated in Figure 1.
• Business Transaction 2–Four-Party Atomic Swap of Treasury Bills for Commercial Paper:
  Scenario: Entity A begins its economic activity, where part of its business objective is to purchase commercial paper from Entity C, and Entity C requires payment in Treasury bills in exchange for commercial paper. Entity A does not hold Treasury bills but its parent company, Entity B, does. Entity A requests Treasury bills from Entity B to enable the purchase of commercial paper from Entity C. Subsequently, Entity B lends Treasury bills to Entity A, which then uses them to purchase commercial paper from Entity C.
  Implementation: The BFS system executes this four-party atomic swap using BFS smart contracts. Step 1: Entity B transfers Treasury bills to Entity A. This transaction is executed by two parties: the lender wallet of Entity B and the borrower wallet of Entity A. Step 2: Entity A transfers the Treasury bills to Entity C in exchange for commercial paper. This transaction is executed by two parties: the employee wallet of Entity A and the counterparty wallet of Entity C.
• Second Accounting Transaction:
  Scenario: The accountant of Entity A records the acquisition of commercial paper and the corresponding use of Treasury bills in its accounting records.
  Implementation: The accountant wallet of Entity A initiates the second accounting transaction smart contract, as illustrated in Figure 5. BFS accounting smart contracts transform the economic data generated by the second business transaction into accounting data and post this accounting data in the accounting journals and ledgers of the BFS system that belong to Entity A. Final financial statements are automatically generated and appended to the BFS filing history blockchain, ensuring the accuracy and transparency of Entity A’s financial reporting data. These final financial statements are published in the Bitcoin-inspired data structure of Entity A’s BFS filing history block, as illustrated in Figure 1. This ensures that Entity A’s financial statements accurately represent its current financial position utilising the tamper-proof nature of the cryptographically linked blocks in the adapted blockchain architecture.

This hypothetical use case is designed and implemented to demonstrate the BFS system’s capability to handle complex business and accounting transactions. By adapting components from the technological innovations inspired by Bitcoin and Corda blockchains, the BFS system ensures the data integrity, transparency, and timeliness of financial records, facilitating better financial management and decision-making for business entities. The innovative architecture and practical implementation of the BFS system present a solution for modern digital financial reporting and accounting needs through secure, automated, and verifiable transactions.

6. BFS Architectural Approach

Wieringa [36] describes a system as an assembly of elements that interact to constitute a whole. The author further notes that the components themselves might be systems composed of lower-level components or they can be integrated into more complex systems. To facilitate the iterative stages of DSRM, it was necessary to select an architectural approach that aligns the software architecture with the complexities of the business domain and its processes. The Domain-Driven Design (DDD) architectural pattern [39] was chosen to enable the comprehensive integration of a blockchain-enabled framework with accounting standards and business reporting requirements, serving as a systematic process for designing the BFS architecture. DDD is instrumental in harmonising blockchain’s advanced capabilities with the specific demands of accounting and business reporting. The core components of DDD utilised for the design and implementation of the BFS artefact are as follows:

• Top-level domain—This is defined as the subject area around which an entire software solution, such as the BFS system, is structured. It serves as the foundation upon which all other aspects of the software are developed, integrating critical elements of blockchain technology, financial accounting, and business entity management into a cohesive whole.
• Domain and sub-domain models—These function as conceptual object models that delineate various aspects of the overarching top-level domain. These models encapsulate both the behaviour and data necessary for the BFS system, illustrating the required information and its organisational structure. By defining these models, the BFS system clarifies the data interactions and functionalities needed across different segments of the business and technological processes, facilitating precise and efficient implementation.
• Bounded contexts—These represent granular subsets within the broader system that encapsulate the internal complexities of each sub-domain. They are specifically tailored sections of the model where distinct aspects of the project’s functionality are isolated and managed. By defining clear boundaries around these contexts, the architecture ensures that the specific requirements and functionalities of each domain are addressed precisely, without interference from others, thereby maintaining coherence and integrity throughout the system.
• Ubiquitous language—This is the common domain language used for describing and understanding entities, elements, methodologies, and all relevant components within domain models and bounded contexts.

According to [40], in DDD, a business domain refers to a specific area of business expertise or knowledge, processes, and rules that the software system is designed to address or support. It ensures that the business rules and behaviours are encapsulated within that domain’s entities and its services promote a clear understanding and representation of the implementation. It prioritises creating a software model that mirrors complex business entities, reflecting their relationships and business rules to enable their interactions.

At the heart of the BFS system is its primary top-level business domain model (see Figure 6), described as “an economic entity that leverages blockchain technology, customised to serve as this entity’s financial accounting system”. This technology continuously records and periodically reports on the economic activity of such an entity and provides verifiable, on-demand validation of the financial health of the entity based on its past transactional interactions. The architecture (see Figure 6) of the overall business domain model for the BFS system consists of three primary sub-domains: financial accounting, blockchain, and business entity.

In DDD, bounded contexts are responsible for defining clear boundaries within the application’s system, encompassing a specific subset of the domain model. Together, these contexts ensure that a software solution, such as the BFS system, is modular, with each module having a distinct and well-defined role. By dividing the design of the architecture of the BFS system and its implementation into distinct bounded contexts, as illustrated in Figure 7, the design strategy for this architecture achieves clarity and focus. The modular architecture of the BFS system is designed to address the complexities of a business entity, its transactional interactions and essential accounting processes, and the integration of blockchain protocols within these contexts. Contextualising this process helps clarify the specifications for integrating accounting and financial reporting within the blockchain framework, thereby reducing complexities and easing its adaptability to changing requirements or emerging needs. For example, the financial accounting sub-domain adapts traditional accounting roles, processes, and procedures within the BFS system. This sub-domain is organised into several bounded contexts, each tailored to address specific financial accounting needs while meeting the technical requirements for integrating with blockchain technology. This ensures that the BFS system is a comprehensive and user-centric solution capable of adapting to the evolving demands of financial reporting and liquidity management. Similarly, the BFS system utilises the blockchain sub-domain to record and report the business activities of a single economic entity. It is customised to cater specifically to the requirements of financial statement representation and to facilitate transactional processes. This sub-domain is structured around its key components, such as its unique block data structure, novel smart contracts, and consensus mechanisms, which are tailored for integrating blockchain technology within traditional accounting processes. Lastly, the business entity sub-domain covers elements such as company incorporation, business-specific aspects, and the roles and responsibilities of business participants. These are essential for defining the operational framework of an entity and its transactional interactions within the BFS ecosystem, ensuring cohesive and efficient business processes.

This strategic segmentation into sub-domains and bounded contexts enhances the clarity, modularity, and effectiveness of the BFS architecture, making it well suited to managing and reporting financial activities within a dynamic business environment.

7. BFS Architecture Components

Back in the late 1960s, Melvin Conway made an observation, which has become known as Conway’s law [41], regarding the design of software architecture:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

The organisation of the BFS system’s components and the orchestration of their behaviours are vital for ensuring the overall ecosystem performs related processes and responds to events. The interdependencies and interactions among these components are not random but are strategically guided by the business logic embedded within the bounded contexts of the BFS artefact. This logic ensures that the interactions align with the system’s objectives and operational principles. Mapping the definitions of the architectural components of the BFS system within the boundaries of the identified sub-domains and their constituent bounded contexts ensures that all interactions and dependencies adhere to business mechanisms. This ensures an accurate reflection of the requirements necessary to meet the business needs of its users.

In Figure 8, an illustration of the key BFS components is presented. These are categorised by their taxonomic relationships, which help in classifying and understanding the roles and functions within the BFS system. Furthermore, cardinality associations elaborate on how these components are linked, detailing the extent and nature of their relationships [36]. These associations are important for interpreting the dynamics of the BFS ecosystem and understanding how changes in one component might affect others.

In the BFS system, a business entity refers to a legally recognised economic unit created by one or more individuals to carry out the functions of a business. It is an organisation, such as a company or financial institution, that participates in the BFS ecosystem. Each business entity has its own unique set of business processes, rules, and requirements, which are encapsulated within the business entity sub-domain. BFS entities interact with one another through transactional smart contracts in the blockchain sub-domain and are responsible for maintaining their own financial records and reporting their financial activities through the accounting sub-domain in the BFS system. This modular relationship flow within the BFS architecture allows for efficient treatment of each business as an individual accounting unit, with financial records maintained utilising a blockchain data structure—the BFS filing history.

7.1. Actors, Roles, Elements, and Fundamental Processes

In the BFS ecosystem, each business entity is composed of various members who perform specific roles critical to business operations, such as directors, borrowers, employees, and accountants. These roles define the responsibilities and relationships each individual has within their respective entity. Beyond these individual roles, the primary actors within the BFS ecosystem include the business entities themselves, which engage in interactions with a network of transactional counterparties, including shareholders, lenders, and other entities involved in business transactions. This organisational structure ensures that every entity and its members are interconnected through well-defined roles and interactions, promoting transparent governance and streamlined operational procedures within the BFS framework.

Wallet. Withn the BFS ecosystem, the wallet is a fundamental component that facilitates role and transactional operations. Positioned within the blockchain sub-domain, the wallet functions as an abstract superclass for all specialised wallet types utilised in the BFS system, as depicted in the BFS architecture diagram (see Figure 8). This superclass is critical for managing cryptographic identities and relevant transaction records, ensuring that each participant, from directors to accountants, interacts securely and efficiently within the BFS environment.

The wallet is designed to be extensible, with derived classes inheriting its basic capabilities while introducing additional functionalities to address the specific requirements of various business roles. This design allows for the customisation of wallet features to suit distinct business use cases, enhancing the BFS system’s adaptability across different economic activities. As a multifunctional tool, the wallet not only safeguards cryptographic keys but also controls access permissions, ensuring that users can only execute transactions or access data pertinent to their roles. Moreover, the wallet acts as a secure repository for cryptographic identities and a robust mechanism for the encryption and decryption of transactional data and HTLC secrets. This multi-functionality enhances the integrity and confidentiality of data within the BFS system, making it a critical component in the architecture’s aim to provide a secure, transparent, and efficient financial reporting and transaction platform.

The wallet is further categorised into member wallet and counterparty wallet types related to each BFS entity, which are illustrated in Figure 4 and described as follows:

• Member wallet: This wallet represents individuals or entities that have ownership or interests in this entity or are employed by this entity in any capacity. This wallet type is registered with its BFS entity and is awarded role-relevant functionality and full or enhanced access rights to the internal BFS data, e.g., directors, employees, and others. Figure 4 illustrates an example of two member wallets owned by a director and an employee of the dark-blue BFS entity. Additionally, a single member wallet of the purple entity is indicated in a darker purple in Figure 4 and is a part of that entity’s personnel.
• Counterparty wallet: This concept for a wallet is based on a “customer account” registered with an e-commerce website. For example, in Figure 4, for the purple entity to transact with the dark-blue entity, one or both of them have to register a counterparty-type wallet with each other. This counterparty wallet (light purple or light blue in Figure 4) is part of the corresponding BFS infrastructure, although it is owned by another BFS. Furthermore, the counterparty wallet supports a direct communication channel with its owning BFS. This data communication channel is called a “source of funds” (see the green arrows in Figure 4) and is utilised to move escrow funds to cover transactional liabilities.

Specialised Wallets. In the BFS architecture, wallets extend the foundational wallet superclass to cater to specific distinct business roles within the business ecosystem. These specialised wallets incorporate unique functionalities tailored to the needs of different actors, each designed to facilitate distinct transactional and operational requirements within its ecosystem. The design and functional implementation of these wallets—DirectorWallet, ShareholderWallet, BorrowerWallet, LenderWallet, and so on—illustrate key architectural characteristics vital for a resilient and adaptable blockchain-based system. These characteristics include adaptability, extensibility, portability, and flexibility, which collectively ensure the BFS system’s longevity, scalability, and robustness in a rapidly evolving technological landscape.

Wallet Register. This is an application-local off-ledger context-specific repository designed to manage and facilitate relationships between the BFS company and its internal members, related parties, stakeholders, and external transactional counterparties through a well-defined wallet registration and management system. This repository acts as the registry for every wallet associated with different categories of BFS participants. This comprehensive registry is integral to the BFS system’s operational infrastructure, ensuring that each wallet associated with the various categories of participants is accurately registered for role-based updates and is readily accessible. The wallet register not only simplifies the management of these relationships but also enhances the security and efficiency of transaction processing within the BFS ecosystem.

Accountant. This role is conceptualised as a specialised wallet within the accounting sub-domain, serving as a digital representation that encapsulates the financial identity and capabilities of an accountant on the blockchain. This role is typically assigned to a hypothetical individual employed by a business entity within the BFS ecosystem. As such, the accountant wallet acts as the digital custodian and manager of the company’s financial accounts. Functionally, the accountant wallet interacts directly with the BFS system’s accounting ledgers and financial reporting components. It is responsible for recording and reporting the economic activities of its BFS entity, ensuring that all data are accurate, timely, and compliant with established financial standards. This role is critical for generating financial statements that provide insights into the financial health of the business.

The BFS architecture leverages automation to enhance the efficiency and accuracy of processes traditionally performed by accountants. By automating routine accounting tasks, the accountant wallet minimises the risk of errors and frees up human accountants to concentrate on more strategic tasks, such as financial analysis and advisory services. This integration of blockchain technology into the accounting processes not only streamlines operations but also significantly enhances the overall reliability and transparency of financial reporting within the BFS ecosystem.

Account. This is a fundamental component within the financial accounting framework and is utilised for systematic recording and reporting of economic variables, expressed in monetary units [9]. Each account functions as a marker for uniform shifts in liquidity related to specific business operations aspects. Within the BFS system, an account is conceptualised as an identifier for homogeneous units of digital value, designed to either aggregate monetary values into distinct categories (child account) or accumulate these values into broader classifications (master account). This structure enables the BFS system to present a consolidated “ending balance” for each category, ensuring clarity and precision in financial communication. The high-level organisation of accounts in the BFS system is illustrated in Figure 9. It is hierarchically structured within the BFS system’s accounting framework. Each account is uniquely identified by an AccountID and its name. These accounts are systematically consolidated by AccountCategory and further grouped under AccountClass, enabling the streamlined compilation of BFS. The internal logic of a hierarchical numbering of accounts contributes to a deeper understanding of the nature and the role of each account within the financial accounting framework [9] which, in turn, is designed to reflect the business activity of an economic entity.

• AccountID is a fundamental element in accounting [9]. In the BFS system, each AccountID is structured to allow comprehensive tracing of transactions affecting account balances within a given accounting period. Additionally, these identifiers are integral to the operation of accounting smart contracts, linking business transactions to appropriate accounts for consistent recording in journals and accurate reflection in financial statements.
• AccountCategory is an enum designed to enable the standardised and hierarchical consolidation of accounts within a specific AccountCategory. The ordering of AccountCategory can contain elements such as CASH(), OTHER_ASSETS(), and more. This alignment with traditional accounting practices within the BFS system serves as a standardised categorisation structure for the representation of financial information for the purposes of reporting, analysis and decision-making [9].
• AccountClass is an enum that enables the standardised consolidation of accounts within each AccountCategory into key categories and classes [9]. These classes are represented within the BFS system as the enum AccountClass and can contain elements such as assets, liabilities, equity, income, or expenses.

Chart of Accounts (COA). Another component illustrated in Figure 9 is an application-local repository for a pre-established, logically organised list of all recognised and authorised accounts used for recording all transactions the business can engage in [9]. Accounts in the COA are assigned a unique AccountID and are hierarchically organised based on that ID within the COA data structure.

Accounting Journals and Ledgers. These are the BFS system’s application-local off-ledger data repositories, where the BFS system systematically records accounting data in chronological order throughout the accounting period [9]. As business transactions are completed, economic data, in real time or on demand, are captured and processed by accounting smart contracts. These data are then recorded in the following:

• General Journal (GJ): A data repository for a day-to-day chronological registration of accounting information on all ongoing allowable transactions [9]. It is the first point of entry for the data from completed business transactions, transformed through accounting transaction smart contracts.
• General Ledger (GL): A data repository within the BFS system for a set of homogeneously defined accounts, classified to contain cryptographically linked chronological details of the relevant side of the accounting entries and provide an ending (aggregated) account balance [9]. Traditionally, only monetary values are posted to the relevant accounts in the GL—GeneralLedgerAccount. However, in the BFS application, the existing traditional data structure is significantly enhanced by integrating innovative blockchain concepts:

  –

  Utilising Corda’s “Transaction Vault” [12] framework, the BFS system embeds a layer of blockchain traceability within each entry of the GeneralLedgerAccount. Each of these entries additionally contains a list of unique cryptographic hashes from relevant business transactions, together with cryptographic hashes of accounting smart contracts that govern the accounting rules for the value posted within GeneralLedgerAccount. This novel feature ensures that the provenance of each financial record is securely and persistently stored, enhancing the integrity and verifiability of the BFS system’s accounting records.

  –

  Variables from GeneralLedgerAccount and its entries are utilised by the validator of the BFS system to facilitate input values within the novel BFS UTXO model and in the BFS system’s funds verification consensus mechanism.

• Trial Balance (TB): A list of the debit and credit entries and footings for each ending account balance from the GL. This is the last repository prior to the publication of the final financial statement reports within the BFS system’s filing history.

Financial Statements. These are the outputs of the accounting process forming a reporting package through a balance sheet, income statement, etc. [9]. They contain anonymised and aggregated data on business transactions over a selected accounting period published in the block of the chronological filing history in the BFS system. In the BFS system, the financial statements are constructed in accordance with the double-entry accounting practices in [9]. The top-level components critical for the construction of the BFS system’s financial statements are ReportEntry, Report, enum ReportType, and final FinancialSatements. They are described as follows:

• ReportEntry is an elemental data structure that represents the final balance entry extracted from the GL. In the BFS system, each instance of ReportEntry for the financial statements contains a map of all cryptographic identifiers of the completed business transactions that affected this reporting value. This feature ensures that the origin and authenticity of every financial record can be securely traced back to its source, significantly enhancing the transparency, security, and reliability of published reports. This innovation makes accounting falsification challenging, providing regulators with an additional data authenticity tool within the domain of financial accounting and potentially setting a new standard for auditability and verifiability in the digital age.
• Report is an integration of the traditionally defined financial report, such as a “balance sheet”, within the BFS system.
• enum ReportType is an initial categorisation mechanism for generating financial statement reports. This enumerator serves as a final consolidation tool for the hierarchical grouping of accounts. Each element of this enumerator also marks the type of financial report added to the final reporting package.
• FinancialSatements is the final packaging for all reports for this accounting period. This object is the one that will be subsequently packaged within the data structure of the block in the filing history blockchain, as illustrated in Step 7 of the accounting cycle in Figure 5.

Account to Financial Statements Data Flow. Figure 10 illustrates the process of data communication across several contexts within the BFS architecture, grouped into “Journals and Ledgers”, “Account and its Hierarchy”, “Financial Reporting”, and “Blockchain”. This data flow is essential for understanding how the BFS system follows traditional accounting practices. It demonstrates the logical path of data that underpins the generation of a financial statement such as a “balance sheet”.

The data flow model demonstrates how the hierarchical data structure for the consolidation of accounting information is designed within the BFS system and further reinforces how the data path is designed in the BFS system’s accounting flow. By incorporating traditional accounting practices within the design and implementation of the BFS system, the COA repository houses accounts that do not contain monetary units. This data flow further showcases how these fundamental financial accounts that do not contain monetary units are processed to derive values from the ending balance of GeneralLedgerAccount in the GL for the corresponding AccountIDs, together with the cryptographic transaction hashes and public keys of counterparties, ensuring the origin and authenticity of every financial account.

Figure 10 illustrates the data flow and key BFS elements instrumental in the preparation and presentation of financial statements. The generation of financial statements is Step 6 of the accounting cycle and is illustrated in Figure 5. The data flow illustrated in Figure 10 is initiated, e.g., at the end of the reporting period, on demand, or instantaneously, as part of the process of generating financial reports. The steps of the data flow illustrated in Figure 10 are as follows:

• Utilising AccountID, the account is retrieved from the COA repository;
• Every account is assigned an AccountCategory field at the instantiation of this account. This AccountCategory field is mapped to a particular accounting category, such as “cash”;
• This AccountCategory field is then consolidated within AccountClass into a group, e.g., “assets”;
• This group is then further consolidated by ReportType into a grouping for the financial report, such as a balance sheet;
• This ReportType grouping will govern the mapping hierarchy within the final financial statements for each Report when generated;
• Concurrently, the final closing value, together with the relevant provenance data from the GL, is instantiated into a new ReportEnrty for each AccountID published in the financial statements;
• These ReportEnrty instances are collected within the relevant Reports, where they are hierarchically arranged based on their AccountIDs, providing the structural integrity of the traditional financial statement;
• Next, in the final Report, the AccountClass grouping is employed once more to logically consolidate the relevant ReportEnrty instances;
• In the final step in the generation of FinancialStatements, the mapping between each ReportType and the corresponding Report is completed;
• Lastly, agreed and hashed FinancialStatements are published as part of the data structure within the BFS system’s block.

Accounting Transaction Register. This is an application-local off-ledger repository for all accounting transaction smart contracts of the individual economic entity. Beyond recording business transactions, the accountant is responsible for overseeing all accounting transactions. This involves translating business activities into accounting entries that reflect the financial implications of these activities, ensuring compliance with relevant accounting standards and principles.

Block. This is a container for the final publishable accounting data, such as financial statements. In the BFS system’s architecture, a block can contain a number of data types, replicating the filing requirements established in the documentation published by Companies House [42]. The BFS system example illustrates two data types stored in separate blocks (see Figure 1). Unlike the standard Bitcoin-style blockchain, where each block stores homogeneous data types such as transactions, the blocks in the BFS system’s filing history chain are designed to store a variety of standardised data types. These data types are determined by the kinds of documentation that economic entities are required to submit to Companies House. In designing the BFS system’s artefact, the simplified representation of the distinct data types published in the blocks of the chain are (see Figure 1) (1) incorporation data block type, and (2) accounting data block type.

Blockchain Filing History. The Bitcoin-style data structure is a cryptographically linked chronological chain of blocks. In the BFS system example, we present a blockchain consisting of two blocks—an incorporation block (height 0) and an accounting block (height 1). This is illustrated in Figure 1.

Validator. Within the blockchain sub-domain in the BFS system, this role is critical to the implementation of the consensus process and UTXO model implementation.

• UTXO: In the BFS system, UTXO is designed as a process, not a data model. It is utilised by the BFS system’s consensus mechanism and is a novel method relevant to accounting. It utilises accounting transaction smart contract functionality to fetch the latest entry from the relevant accounts in the GL to provide pre-settlement verification of monetary claims made by the counterparties of the business transactions, ensuring that the offered funds are available.
• Consensus: The BFS system employs a “funds verification” consensus mechanism that introduces a novel approach to verifying transactional integrity within a blockchain-integrated accounting framework. This method ensures the economic validity of transactions by comparing the transaction value against the available funds in the latest accounting records of an economic entity, confirming that sufficient funds exist to cover the transaction. Unlike traditional consensus mechanisms that seek broad network agreement, the BFS system’s consensus model focuses on bilateral verification between transacting parties, utilising accounting data to confirm the financial soundness of transactions without revealing sensitive details. This targeted approach leverages concepts from Zero-Knowledge Proofs (ZKP) to maintain privacy, confirming the truthfulness of fund availability claims to the involved parties without disclosing any further financial information.

The design and implementation of the BFS system introduces a novel approach to the role of validators within the blockchain network, specifically tailored to enhance the transparency, efficiency, and integrity of financial reporting. Furthermore, unlike traditional blockchain models where validators add blocks to a blockchain, in the BFS system’s design, the responsibility for adding blocks is reserved for an accountant and can involve the explicit approval of the company directors. This design decision was motivated to align the functionality of the BFS system with traditional accounting reporting practices. The validator’s role is redefined to focus solely on the following:

• Verifying the integrity of transactional data, including checks for the completeness, accuracy, and consistency of transactional data;
• Verifying the validity of signatures to confirm that transactions have been initiated by legitimate parties and have not been tampered with during transmission;
• The tokenisation process, which involves converting sensitive data into non-sensitive data tokens that can be shared within the blockchain ecosystem. Tokenisation helps to maintain data privacy while allowing transactions to be processed and verified on the network. The BFS project uses tokenisation to facilitate the transfer of ownership of financial assets relevant to the use case. Examples of financial assets tokenised in this project include shares, share certificates, commercial paper, and Treasury bills.

This specialised design and implementation of the roles and responsibilities of the validator ensures that it concentrates on the accuracy and authenticity of transactions without being involved in block creation, thereby streamlining the validation process and enhancing system security. By separating the roles of validator and accountant, the BFS system’s design enhances the focus on transactional integrity and privacy.

Shares and Share Certificates. These are examples of traditional financial assets utilised in the digital infrastructure of the BFS ecosystem. These assets are issued by BFS-enabled business entities through processes of tokenisation. A share certificate represents a tokenised document that demonstrates the purchase of shares from the share issuer by the shareholder. This tokenised certificate pertains to all relevant details relating to the shares that have been acquired on a certain date by a particular shareholder. During a business transaction, this certificate is generated and transferred to the shareholder’s ownership.

Commercial Paper and Treasury Bills. These are examples of debt assets issued and traded during business transactions between BFS entities. For these financial instruments to be utilised in the digital infrastructure of the BFS ecosystem, they undergo a process of tokenisation.

Digital Funds. In the BFS ecosystem, digital funds are essentially digital representations of value that are securely exchanged on the BFS platform during transactions, such as the purchase of tokenised shares.

Business Transactions Register. Drawing parallels from Corda’s “Transaction Vault” architecture and its functionality [12], this class serves as a chronological archive of economic activities, where transaction records are stored and managed. In Corda, the vault is a database containing ledger data considered relevant to the owner of the wallet, and it is stored in a chronological model and in a form that can be both easily queried and worked with [12]. Another justification for the innovative design of the business transactions register within the BFS system is that it provides a solution for the event broadcasting communication methods of the traditional Bitcoin-style blockchain. The design of the business transactions register represents a response to privacy concerns posed by these blockchain communication methods. The BFS system counters this by integrating Corda’s Flow Framework ([11]) and Transaction Vault architecture [12], offering point-to-point messaging and an off-ledger transaction repository. This design ensures that business-sensitive information is only accessible to relevant parties, thereby maintaining confidentiality while allowing transaction traceability. This approach preserves privacy and supports compliance and transparency, addressing critical challenges within the BFS framework.

7.2. Key Smart Contracts

The concept of smart contracts in the BFS system defines the rules generated to enable automation of business and accounting processes, which can be uniquely tailored to each economic entity’s needs. These bespoke, diverse digital protocols are designed to facilitate, verify, or enforce contractual or transactional agreements, executing automatically when predefined conditions are met, without the need for intermediaries. They are designed to operate within the BFS ecosystem, ensuring transparent and tamper-proof automation. In the BFS system, smart contract capabilities are utilised to automate rules for executing the following:

• Business transactions;
• Accounting transactions;
• The accounting cycle.

Business Transaction Smart Contract. An economic ecosystem/network consists of heterogeneous economic entities (i.e., businesses or business entities). These entities are interconnected via fundamental units of interaction—business transactions. These interactions represent diverse economic events in the BFS ecosystem that have or will have monetary implications, i.e., they will result in the exchange of digital funds or digital assets at some point. A transaction represents the movement of value (digital funds or digital assets) from BFS wallet addresses to other BFS wallet addresses. To provide a standardised way of executing a diverse and ever-evolving set of economic interactions, the BFS system provides a solution in the way of a framework for business transaction smart contracts. These represent events of an economic nature with monetary implications for the business. According to [9], transactions that are not explicitly completed at the end of the accounting period are considered open [9]. In our architecture, only completed transactions are pushed through the accounting cycle.

Accounting Transaction Smart Contract. This represents a novel design for a BFS-specific implementation of a traditional smart contract model. It is a set of pre-defined smart contract rules that govern the transformation of transactional data into accounting data, their classification into respective accounts, and the aggregation of values into corresponding accounting journals (ledgers). Each individual accounting transaction has two sides (debit and credit) that are always balanced [9].

Accounting Cycle. This is a critical and fundamental concept in financial management, representing a series of steps undertaken to ensure accurate and comprehensive recording and reporting of an entity’s financial activities [9,43]. Depending on the requirements, the accounting cycle can be described in 4, 5, or even 10 steps. However, the general consensus is that there are eight steps, and this concept is adapted for the BFS system’s design and implementation. The process starts with the initial identification, collection, and analysis of business transactions, leading to their recording in journals and posting to the general ledger, etc. It progresses through the preparation of trial balances, adjustments, and the creation of adjusted trial balances, culminating in the preparation of financial statements, their communication, and the closing of the books for the accounting period [43].

The accounting cycle is a comprehensive process employed by businesses to ensure that their business transactions are accurately recorded, processed, and reflected in their financial statements. Our adaptation of the accounting cycle is illustrated in Figure 5. The BFS system’s accounting cycle includes the following eight steps:

• Identifying and Analysing Business Transactions. The financial accounting cycle only recognises transactions that have or will have monetary implications, i.e., those resulting in an exchange of funds at some point [9]. These transactions are collected for processing within the same accounting period, and their impact on the company’s finances is assessed.
• Activating Accounting Transaction Smart Contracts. This step involves gathering economic descriptors about business transactions. It is facilitated through accounting smart contracts designed to enhance efficiency and reduce errors, making the whole process more streamlined and reliable. These accounting smart contracts define the accounting rules that govern the transformation of economic data produced by business transactions into accounting data. This process ensures adherence to a set of rules for recognising which financial accounts will be impacted by each business transaction.
• Recording Transactions in a General Journal. After identification, the transformed data from business transactions are recorded chronologically as journal entries in the company’s books, starting with the general journal (GJ).
• Posting Transactions to the General Ledger. Entries from the GJ are then posted to the general ledger (GL), a master record that provides a complete overview of all financial accounts and the evolution of their values.
• Generating Entries for the Running Trial Balance. At the end of the accounting period (continuously or on demand), the final balances from the general ledger are automatically calculated, ensuring accuracy and reducing the potential for errors or manipulations. Only these final balances are posted to the running trial balance, clarifying details from the GL account. This step is necessary to ensure that debits equal credits, essential for analysis, error identification, and corrections to ensure the accuracy of financial records before financial statement preparation. The resulting final trial balance is used to construct the financial statements—the end product of the accounting reporting.
• Generating Financial Statements. Adapting this step to the BFS system’s architecture involves automating the generation of the final balance sheet from the finalised running trial balance. The balance sheet is a critical financial statement summarising a company’s financial position at a specific point in time, detailing assets, liabilities, and shareholders’ equity. By automating the generation of the balance sheet, the BFS system ensures accuracy and reduces the potential for human error, facilitating a more efficient and reliable financial reporting process.
• Publishing the Financial Statements on Blockchain. The penultimate step in the BFS system’s accounting cycle is the publication of the balance sheet in the blockchain financial statement data structure, referred to as the filing history of the BFS system. This integration into the blockchain ledger secures the financial information against unauthorised alterations and enhances the auditability of financial statements. By leveraging blockchain’s inherent properties of immutability and transparency, this step ensures that financial data are readily verifiable and accessible, thereby providing confidence among stakeholders and regulatory bodies.
• Closing the Books. Finally, temporary accounts are closed out to permanent accounts, like retained earnings, and the company prepares for the next accounting cycle.

The adaptation of traditional accounting cycles to incorporate blockchain technology into the BFS system addresses several critical problems within financial reporting and management. This innovative approach solves issues related to accounting fraud, data manipulation, and the timeliness and reliability of financial data. By leveraging blockchain’s inherent properties of immutability, transparency, and security, the BFS system ensures that all financial transactions are accurately recorded, processed, and verified in real time or on demand. This enhances the integrity and trustworthiness of financial statements and facilitates a more efficient and transparent audit process. Consequently, the adaptation contributes to a more stable, secure, and equitable economic ecosystem, where stakeholders can confidently rely on the financial information presented, fostering a higher degree of accountability and trust among all parties involved.

8. Implementation and Discussion

The BFS system, as evidenced by its implementation, offers transformative potential in financial reporting and liquidity management. By adhering to the architectural framework of DDD, the BFS system prototype demonstrates its theoretical feasibility and practical effectiveness in developing a technically sound and domain-aligned modular solution capable of integrating blockchain technology within the financial reporting domain and aligning with business orchestration needs. The Java-based prototype of the BFS system demonstrates its functionality, encapsulating the dual-blockchain framework, smart contracts, and interaction dynamics among various system actors, such as business entities, counterparties, validators, and accountants. This setup demonstrates how the BFS system can facilitate secure, efficient, and transparent financial transactions within an integrated ecosystem. This approach ensures that the complexities within the wide business domain in the BFS system and the interactions of its components are accurately modelled and implemented. Overall, the BFS system prototype not only confirms the feasibility of integrating blockchain technology into financial and accounting systems but also highlights the practical benefits of this integration for enhancing the transparency, efficiency, and security of financial operations.

The BFS framework serves as a conceptual basis for a blockchain-based accounting system. Our focus here is on establishing the fundamental architecture, components, and interactions within the proposed framework. Specifying detailed efficiency metrics, such as data throughput, volume, query capability, or energy consumption, and setting corresponding baselines would require a fully functional implementation and extensive testing. Similarly, a thorough security assessment, including identifying potential attack vectors, attacker resources, and motives, necessitates evaluating an implemented system. The BFS framework uses key features of blockchain technology, such as immutability, decentralisation, and cryptographic mechanisms, which can enhance the security and transparency of the accounting system. The proposed framework also aims to improve data accessibility, enable real-time reporting, and streamline processes, potentially increasing efficiency in accounting practices. However, further research and development are needed to fully realise and validate these potential benefits. Future studies should focus on implementing the BFS framework, defining the relevant metrics, and conducting rigorous evaluations to assess its efficiency and security against established baselines and potential threats. This approach will help address the specific requirements and objectives of the system and provide a better understanding of the practical implications of the BFS framework. Despite these limitations, our work provides a valuable starting point for exploring the application of blockchain technology in accounting systems and lays the groundwork for future advancements.

8.1. Discussion

This project’s journey revealed multiple layers of complexity involved in the integration of blockchain technology into financial reporting processes and liquidity management, aiming to enhance transparency, security, and efficiency. At its core, the BFS initiative seeks to address pressing challenges in the domains of accounting and business management, including but not limited to the integrity of financial reporting, the agility of liquidity provision, and the overarching quest for trust and transparency among economic entities and liquidity providers. In navigating these discussions, the objective is to offer a comprehensive understanding of the BFS project’s contributions to the fields of blockchain, finance, and accounting, setting the stage for ongoing innovation and exploration in this dynamic and rapidly evolving domain.

Technological Approach—Dual-Blockchain Framework Integration. At the core of the BFS system’s domain model lies the innovative application of blockchain technology, tailored to function as a comprehensive financial accounting system for economic entities. This model is central in transforming raw economic data into financial reports that are cryptographically secure and verifiable on demand. The dual-blockchain framework integration is a testament to the project’s technological innovation, presenting a solution that harmonises the strengths of two distinct blockchain architectures to overcome the limitations of each and improve traditional financial reporting.

The technological stack designed and implemented for the BFS system reveals how the ecosystem functions as a network of distinct economic entities. Each entity maintains individual financial statements or BFS filing histories, summarising its unique economic engagements. This decentralised yet coherent structure for financial reporting is critical for understanding the BFS system, as its Java implementation operates within a multi-ledger ecosystem. This technological approach ensures the following:

• Immutable and Verifiable Data: The BFS system’s architecture leverages blockchain’s inherent tamper-proof nature, ensuring that all transactional data reflected in financial statements are immutable. This feature directly addresses the issues of data integrity and trust in financial reporting.
• Privacy and Accountability: The dual-blockchain framework, incorporating elements from both the Bitcoin and Corda platforms, enables a balance between the need for transactional privacy and the requirement for accountability. While the Bitcoin framework provides an immutable, cryptographically linked data structure for the BFS system’s filing history, the Corda platform’s Flow Framework and Transaction Vaults introduce a refined approach to data privacy and traceability.

While the dual-blockchain approach employed by the BFS system model offers benefits such as enhanced privacy and accountability, it is important to take into account the potential vulnerabilities and security risks associated with this design. One primary concern is the possibility of data inconsistency or synchronisation issues between the two blockchain networks. If the data on the Bitcoin-inspired blockchain and the Corda-based blockchain are not properly synchronised, it could lead to discrepancies in financial reporting and open avenues for fraudulent activities. Another vulnerability arises from the increased complexity introduced by the dual-blockchain architecture. The interaction between the two blockchain networks and the coordination of smart contracts across them may present additional attack surfaces for malicious actors. The privacy features provided by the Corda-based blockchain, while beneficial for protecting sensitive financial information, could be misused by bad actors to conceal illicit activities. To mitigate these risks, the BFS system model must implement robust security measures, such as secure communication protocols between the two blockchains, regular data audits to ensure consistency, and stringent access controls to prevent unauthorised access to sensitive data. The smart contracts governing the interaction between the two blockchains should undergo thorough security audits and testing to identify and rectify any potential vulnerabilities. The BFS system’s design can also incorporate advanced cryptographic techniques, such as zero-knowledge proofs, to enhance the privacy and security of the dual-blockchain approach.

The BFS system is envisioned and designed to facilitate both continuous and periodic reporting on the entity’s economic activity, offering verifiable, on-demand validation of financial health based on historical transactional interactions. This technological approach to the BFS system prototype demonstrates its operational viability, addressing the need for verifiable yet privacy-preserving techniques in the secure sharing of sensitive financial information. This dual-framework approach highlights the BFS system’s potential as a transformative tool in the realm of financial accounting and liquidity management, offering a blueprint for future innovations in the field.

Block Data Structure. The BFS system’s block data structure is designed to house diverse types of data based on comprehensive mandatory reporting requirements. The block data structure’s versatility is showcased through the encapsulation of various data types, ranging from financial statements to incorporation documentation and more. This diversity ensures that the BFS system can serve as a singular, authoritative source for all financial and regulatory information pertaining to a business entity. The integration is not merely a technical achievement, but a strategic alignment with real-world financial reporting and compliance standards set by traditional financial reporting systems.

The BFS System’s Filing History Blockchain. Central to the BFS system is the filing history blockchain, a novel implementation that serves as a digital ledger for all mandatory reporting of an economic entity. The filing history blockchain illustrates the BFS system’s capacity to digitise and store a wide array of financial and operational data, thus providing a reliable foundation for transparent and verifiable record-keeping. By mirroring the organisational structure and data categories of Companies House’s reporting standards, the BFS system ensures its utility and relevance in real-world financial ecosystems. This ensures the following:

• Immutable and Verifiable Data: The core of the BFS system’s design philosophy is the guarantee of data immutability and verifiability. By leveraging blockchain technology, the BFS system ensures that once a transaction is recorded within the block data structure or the filing history blockchain, it cannot be altered or deleted. This immutability, paired with the system’s inherent ability to verify the authenticity and accuracy of the recorded data, provides stakeholders with a reliable foundation for trust in the financial statements and reports generated by the BFS system.

Wallets and Role-Based Access. The exploration of wallet implementations within the BFS system offers a nuanced view of how digital identities and transactional capabilities are managed and optimised in a blockchain-enabled BFS ecosystem. This strategic approach to wallet design and functionality underscores the BFS system’s commitment to fostering a secure, efficient, and user-centric environment for financial transactions and interactions.

UTXO and Consensus Mechanisms. In the BFS framework, UTXO and funds verification consensus mechanisms are innovatively tailored to fit the nuanced requirements of financial reporting and liquidity management, diverging from their conventional roles in traditional cryptocurrency transactions. This bespoke adaptation aligns with the BFS system’s objective to provide a solution for the real-time validation of financial transactions and the verification of monetary claims, thereby fostering a secure and trustworthy environment for all ecosystem participants. Within the BFS system, the concepts of UTXO and consensus evolve into a uniquely designed mechanism for validating transactional inputs by internally querying the accounting data of an entity using the most up-to-date accounting records without disclosing proprietary information. By integrating UTXO generation into the BFS system’s accounting processes, the system can offer verifiable assurances to transacting parties regarding the legitimacy and sufficiency of claimed funds while maintaining the privacy of sensitive business information. This innovative application of UTXO and consensus mechanisms reduces the risk of fraudulent activities and streamlines the process of transaction validation, ensuring that all network participants adhere to a unified standard of truth.

The BFS system’s strategic application of both UTXO and consensus mechanisms illustrates a bridge between the domains of blockchain technology and traditional accounting. This fusion reinforces the system’s role in advancing the reliability and verifiability of financial documentation. Through these adaptations, the BFS system establishes a pioneering framework for instantaneous transaction validation and a balance between privacy and accountability. This interpretation of the findings from the BFS system demonstrates a significant leap forward in leveraging blockchain technology to foster secure, efficient, and transparent financial management practices. As such, it sets a new benchmark for blockchain applications in financial reporting and opens avenues for future exploration and innovation in blockchain-based accounting systems.

Adaptive Accounting Cycle. The accounting cycle within the BFS system is designed to facilitate automated transactional and accounting processes and can be adapted to the unique business requirements of an organisation. It can be designed to run a full cycle following each business transaction, thereby facilitating the production of distinct balance sheet reports for comparative analysis instantaneously. This process can also be set up on demand and can align with traditional reporting time frames if necessary. This methodology highlights the system’s flexibility, efficiency, and potential to provide immediate or on-demand insights into an entity’s financial health post-transactional activities.

Entries in the General Ledger. The BFS system introduces a novel transformative approach to traditional accounting entries that captures generalised accounting information. In the BFS system, each general ledger entry innovatively incorporates blockchain’s data provenance features. Each of these entries embeds an additional layer for verification through the hashes of source business transactions that created them, aiding in the auditing process by ensuring each record’s traceability and verification. This enables the following:

• Verifiable Transactional Data: The BFS architecture’s core is its ability to produce verifiable transactional data, a fundamental need for all stakeholders within the economic ecosystem. By leveraging blockchain technological processes, the BFS system ensures that each transaction, from its initiation to its final inclusion in the subsequent financial statements, carries a unique cryptographic identifier, ensuring its origin and integrity.
• Real-time Validation of Transactions: In addition to maintaining verifiable records, the BFS system provides real-time validation of transaction capability, particularly critical in today’s fast-paced economic environment, where the timeliness of financial information can significantly impact decision-making and strategic planning. The BFS system employs a dynamic validation mechanism, where transactions are recorded instantaneously in accounting journals and can be validated in real time as they are processed through the accounting cycle. This ensures that stakeholders have access to the most current and accurate financial data, facilitating immediate insight into the entity’s financial activities and status.

By embedding blockchain traceability within each entry, the BFS system provides a tamper-proof record of all financial activities. This feature guarantees the integrity of financial records and supports the system’s role in enhancing transparency in financial reporting.

Implementation of Financial Statements. The BFS architecture’s alignment with the domain-specific requirements of accounting demonstrates its capability to generate accurate and real-time financial reports. This enables the following:

• Real-Time Auditing and Verification with Privacy Preservation: A notable innovation within the BFS framework is the report entry structure within the financial statements. Similar to the ledger entries, it diverges from traditional accounting practices by offering a more detailed view of the accounts in financial reports. Leveraging the data tractability framework of Corda, the BFS system ensures that each transaction contributing to the final balances within the report entries of the balance sheet can be continuously tracked, providing a level of traceability and verification for every record. By enabling this direct link back to the source of each transactional record, the BFS system sets a precedent for future financial reporting standards, potentially revolutionising the landscape of financial auditing and validation in the blockchain era.
• Balancing Privacy with Accountability: In addition to the source hashes, the report entries include a mapping of the encrypted identities of the participants in these transactions within the report entry data. The inclusion of mapping the transactional hashes and encrypted identities reinforces the BFS system’s commitment to accountability while facilitating privacy preservation for individual participants through encryption.

This innovation in financial reporting enables real-time transaction validation and offers a framework for balancing privacy with accountability, ultimately contributing to the construction of a more transparent, secure, and resilient financial ecosystem.

Business Transaction Smart Contracts. The BFS system adapts smart contracts to automate key business transactions, each embodying distinct aspects of business interactions between participants in the BFS ecosystem. These transactions, from share settlements to asset acquisitions and liquidity management, demonstrate the BFS system’s capability to align with traditional financial processes while leveraging blockchain’s inherent benefits of security, transparency, and efficiency.

Accounting Transaction Smart Contracts. The implementation of accounting processes via a novel smart contract design within the BFS system marks a significant advancement in the integration of blockchain technology with conventional accounting processes. This innovative approach facilitates the automation of accounting steps, bridging the gap between the execution of financial activities and their representation within accounting records.

8.1.1. Expected Data Volumes in the BFS System

Hypothesised data volumes stored in a BFS could vary depending on the size and frequency of transactions within the diverse needs of business entities. Based on references to existing systems, here are some anticipated data volumes:

• Each business transaction, including metadata, could range from a few kilobytes to several megabytes, depending on the complexity and the amount of data involved (e.g., digital signatures, transaction details, or timestamps). For a mid-sized enterprise, this could translate to hundreds of transactions per day, each adding a few kilobytes to the BFS system’s business transaction register.
• Accounting data, including journal entries and ledgers, are likely to be smaller but still significant, especially when aggregated over time.
• Financial statements generated instantaneously or at the end of accounting periods will be stored on the BFS system’s filing history blockchain. Each statement, including balance sheets, income statements, and so on, could range from a few kilobytes to several megabytes depending on the complexity and detail. For a large corporation with frequent transactions, the data volume could reach several terabytes over time.
• Overall, the total data volume will depend on the frequency and complexity of transactions and the number of entities involved. Assuming an average of 500 transactions per day, with each transaction consuming around 5 KB, the annual data volume would be approximately 912 MB. Financial statements and other reports would add to this volume, making it feasible for businesses to manage data efficiently on the blockchain.

8.1.2. Anticipated Data Throughput and Query Frequency

Hypothesised data throughput and the frequency of queries in a BFS system are expected to be high, particularly for real-time financial reporting and auditing purposes. These can be anticipated based on typical usage patterns observed in blockchain implementations:

• Transaction processing throughput in comparative blockchain systems can range from a few transactions per second (TPS) to tens of TPS depending on the underlying blockchain technology and network configuration. Advanced platforms such as Corda, designed for high throughput and low latency, are known for high TPS.
• The frequency of queries for accounting data and reports may be frequent, especially during peak periods such as financial audits, regulatory reporting deadlines, and end-of-quarter financial reviews. The frequency of queries can range from a few per day for small businesses to several hundred per day for larger enterprises, and the BFS system’s capabilities should be optimised in future research efforts to accommodate these demands.
• The BFS architecture prioritises overall performance, ensuring that querying is not hindered. By leveraging off-ledger storage for accounting ledgers, the most frequently accessed data, the BFS system maintains high performance by supporting the frequent implementation of the “funds verification consensus” model.

8.2. Conceptual Efficiency of the BFS System

The BFS framework aims to improve efficiency in financial reporting and liquidity management through its architecture. However, it is important to note that as a conceptual framework, specific efficiency metrics such as runtime, memory consumption, or energy usage cannot be quantified without full implementation and testing. Instead, the efficiency of the BFS system can be discussed in terms of process streamlining and data accessibility. For instance, the dual-blockchain approach potentially improves efficiency in data processing by separating public and private information flows, reducing the computational overhead typically associated with processing all data on a single blockchain. The real-time validation capability of the BFS system could enhance transactional efficiency by reducing the time and resources needed for reconciliation and auditing processes. Additionally, the automated smart contract functionality may increase operational efficiency by reducing manual interventions and the associated risk of errors. However, it is fundamental to emphasise that these efficiency gains are theoretical at this stage and would require empirical validation in future research. The true efficiency of the BFS system across various metrics can only be determined through rigorous testing and comparison with existing systems once a full implementation has been developed.

9. Future Work and Conclusions

The BFS system represents a significant step forward in the innovation of financial reporting and liquidity management. The proof-of-concept implementation has demonstrated the feasibility and effectiveness of using blockchain technology to improve transparency, accountability, and operational efficiency in the financial ecosystem. However, there is still work to be done to fully realise the potential of the BFS system and to address the challenges encountered during its development and implementation.

One area for future research is the examination of the economic and regulatory implications of implementing BFS across diverse jurisdictions. This adoption could lead to significant economic benefits, such as increased transparency, reduced fraud, and improved efficiency in financial reporting and liquidity management. However, it also presents several challenges and regulatory considerations. Economically, adopting BFS may require substantial upfront investments in infrastructure, training, and integration with existing systems. Cost–benefit analyses of implementing BFS may differ across jurisdictions, influenced by factors such as the size of the economy, the complexity of financial markets, and the level of technological readiness. Additionally, the economic benefits of BFS, such as increased investor confidence and access to capital, may vary across countries due to differences in market structures and investor behaviour. From a regulatory standpoint, implementing BFS would necessitate close collaboration between policymakers, industry stakeholders, and technology providers to ensure compliance with existing regulations and to develop new frameworks that address the unique aspects of blockchain-based financial reporting. This may involve adapting current accounting standards, data privacy laws, and financial reporting requirements to accommodate the decentralised and immutable nature of blockchain records. Furthermore, regulators may need to consider the cross-border implications of BFS adoption, as the technology facilitates the seamless transfer of financial information across jurisdictions, potentially raising concerns related to data sovereignty and jurisdictional oversight.

Another area for future research is the optimisation of the BFS system’s scalability and performance. While the current implementation has demonstrated its ability to process financial transactions in real time, further research is needed to ensure that the system can handle the massive volumes of transactions generated by the global financial system. The scalability of the BFS system is a critical aspect that requires further examination. The system faces several scalability challenges specific to its design, such as processing complex smart contracts, managing large-scale data storage, and efficiently synchronising multiple blockchain networks. These challenges can potentially limit the system’s throughput and latency, affecting its overall performance and usability. To address these scalability issues, various techniques and solutions can be explored. For instance, sharding, which partitions the blockchain network into smaller, more manageable subsets, can be employed to distribute the computational load and improve transaction processing speeds. Other scalability techniques, such as off-chain transactions, sidechains, and layer-2 solutions, can also be investigated to optimise the performance of the BFS system. Additionally, advancements in consensus mechanisms, such as Proof-of-Stake (PoS) or Delegated Proof-of-Stake (DPoS) mechanisms, can enhance the efficiency and scalability of the underlying blockchain architecture. Empirical studies and theoretical analyses can be conducted to evaluate the effectiveness of these proposed solutions and identify the most suitable approaches for the BFS system. By addressing the scalability challenges and implementing appropriate optimisation techniques, the BFS solution can be made more robust and capable of handling the demands of the global financial ecosystem.

Another important direction for future research is the integration of the BFS system within existing financial systems and infrastructure. Further work is needed to ensure interoperability with the wide range of legacy systems and data formats used in the financial industry. This may involve the development of standardised data models and ontologies for financial reporting, as well as the creation of middleware and translation layers to facilitate communication between different systems.

The BFS system has the potential to be applied to a wide range of use cases beyond traditional financial reporting and liquidity management. Future research could explore the application of the BFS system to areas such as supply chain finance, trade finance, and cross-border payments, among others. By taking advantage of the transparency, immutability, and efficiency of blockchain technology, the BFS system could help streamline and automate many of the complex and time-consuming processes involved in these areas, thereby reducing costs and improving overall efficiency. Moreover, while energy consumption and savings are not the focus of this paper, they represent a highly relevant area for future work that could naturally follow from our work on the BFS system.

Ensuring regulatory compliance and standardisation is a critical challenge in the adoption of any new financial reporting system. Future research could explore the development of standardised compliance frameworks and reporting requirements for blockchain-based financial reporting systems, as well as the creation of industry-wide standards and best practices for the use of blockchain technology in the financial sector. This may involve collaboration with regulatory bodies, industry associations, and other key stakeholders to ensure that the BFS system meets the highest standards of security, reliability, and transparency.

The BFS system represents a significant contribution to the innovation of financial reporting and liquidity management. By using the power of blockchain technology, the BFS system enables real-time, transparent, and auditable financial reporting while also improving the efficiency and security of liquidity management processes. The development and implementation of the BFS system have also highlighted the challenges and opportunities associated with the use of blockchain technology in the financial sector. While there are certainly technical, regulatory, and operational hurdles to overcome, the potential benefits of the BFS system are significant. By providing a transparent, immutable, and efficient platform for financial reporting and liquidity management, the BFS system has the potential to reduce costs, improve efficiency, and enhance trust and confidence in the financial system.

As the financial industry continues to evolve and embrace new technologies, the BFS system represents an important step forward in the innovation of financial reporting and liquidity management. By continuing to refine and improve the system and by collaborating with key stakeholders in the financial ecosystem, the BFS project has the potential to drive significant positive change in how financial information is recorded, reported, and utilised.