Design features

111 6.4 Design principle 4. Component-based (loosely coupled) structure

One of the objectives of this artifact is to test whether DLT is suitable for a nationwide invoicing platform. It is already known that other components are part of the solution architecture

(interview #2, interviews #11-#12). Existing tax systems and DLT components are found, for example, in various configurations, as mentioned by Xu et al. (2018), with the general

(im)maturity of DLT being defined as only 12 years. Therefore, it is important to apply a

component-based structure to the solution so that it is possible to exchange components without compromising the entire architecture. As another important argument for formulating this principle, business requirements will most likely change over time, and without a component-based structure, the required agility level is very difficult to provide from a solution architecture perspective.

112

Figure 3. Digital fingerprint

Figure 3 shows a screenshot from the prototype (headings in Danish) to demonstrate how an invoice (the contract) is made available in the buyer’s and seller’s lists. It also shows the hashed value of the invoice in the column titled Digitalt fingeraftryk.³³

7.2 Design feature 2. Monitoring dashboard

Based on design feature 1, the authorities can monitor the use of the platform through a dashboard.

Figure 4. VAT dashboard

The two graphs shown in the upper part of Figure 4 show the number of VAT transactions executed and their values over a given period. This near real-time information delivery makes it easier to identify cases of fraud and abuse as the data are disaggregated at the company level.

33 ”Digita lt fingera ftryk” in Da nish mea ns „digita l fingerprint‘.

113 The lower part of the dashboard visualizes the use of the platform through three pre-made

matrices:

1. The number of invoices sent through the platform in a given period 2. The response rate (how many issued invoices are answered)

3. The number of corrections made (how many transactions are renegotiated).

Authorities are thus provided direct insight into companies’ business transaction patterns.

Today, authorities have very few touchpoints with companies before they self -declare VATs and submit annual financial reporting.

7.3 Design feature 3. Split payments

The split payment mechanism enables the smart contract to calculate the VAT amount and automates VAT settlement within every transaction as opposed to every month, quarter, or year as in the current VAT settlement paradigm. Whenever a buyer and a seller agree on a

transaction, the smart contract performs the split payment from the buyer to the seller and the authorities. In doing so, the smart contract removes the administrative burden on transacting parties of declaring the VAT while ensuring a better basis for the authorities to ensure the VAT revenue flow. The implementation in the artifact is limited to trivial VAT calculations at a fixed rate. As shown in Figure 3, the transacting parties can use the column “Moms” to see the VAT associated with each transaction.³⁴

7.4 Design feature 4. Permissioned, private blockchain implementation Several important findings emerge from analyzing actors’ design requirements, design

principles, and process flows of the use case. On the one hand, the unambiguous identity of the company, as well as those acting on its behalf, must be determined. This unavoidable

requirement speaks for the selection of a private DLT. On the other hand, the design principles – providing a high level of user access security and a high level of data access security – meet the requirements for access management and data protection. This would imply a need to select a permissioned DLT. After considering both aspects, a permissioned, private DLT implementation appears to be the right fit and is consistent with what other scholars have found (Pedersen et al.,

34 “Moms” in Da nish mea ns “VAT”.

114 2019). Bogdanov et al. (2015) present a secure multi-party approach to balance fraud and

privacy concerns in the context of VAT collection in Estonia. The solution also, however, introduces a trusted third party and presents scalability issues, which is why a blockchain set-up was chosen.

Likewise, the key users of the solution are known to be Danish SMEs, the Danish Business Authority, the Danish tax authorities, banks, and auditors. SMEs gain access to the platform only when using the national e-ID (NemID), which ensures an unambiguous identity. The Azure Blockchain Workbench (version 1.1.0) was chosen because it offers an enterprise-oriented platform in which DLT components act as single pieces when deploying large-scale solutions, which is in accordance with design principles that focus on a component-based structure.

Furthermore, the Azure Blockchain Workbench offers an Ethereum implementation with a proof-of-authority (PoA) consensus mechanism called Aura.

In the PoA paradigm, validator nodes take the place of traditional miner nodes, which are used in the Bitcoin protocol (Nakamoto, 2008), and the public, permissionless Ethereum platform (Buterin, 2013). The Aura implementation of consensus is essentially an optimized proof-of-stake model that utilizes identity as the type of proof-of-stake rather than staking tokens (Parity, 2019).

The identity is staked by a group of validators who are pre-approved to validate transactions and blocks within their respective networks. If this platform is to be a Danish implementation only, the governance model will imply a high degree of centralization toward authorities, raising questions as to why this use case needs a DLT system. When scaling the solution to include transnational transactions, though, one means of scaling would involve adding validator nodes representing authorities (tax authorities, business registry agencies, national statistics, etc.) from other countries. In this way, the power among network participants (countries) is evenly

distributed and by design eliminates this degree of centralization (Lamport et al., 1982). This pattern (segregation of wallets and validator nodes) follows the de facto standards applicable in many other blockchain implementations, e.g., Bitcoin and Ethereum. ³⁵

35 In some DLT systems, it is possible to be both a wa llet a nd a node. In this ca se, though, the chosen design sepa ra tes these roles.

115 Blockchain critics (e.g., Coyne and McMickle, 2017) may argue that many of the benefits of blockchain technology are lost using consensus mechanisms such as PoA. However, because the actors within this network are known, we can relax the assumptions of anonymity that result in the need to use the Proof-of-Work consensus mechanism. In this study, PoA ensures that the actors involved are afforded immutability of data and audit trails while ensuring low energy consumption in comparison with Proof-of-Work. Alternative messaging technologies (e.g., Kafka or Spark) offer a distributed deployment (Chintapalli et al., 2016; Kreps et al., 2011), but the audit trail and immutability based on consensus across nodes are not available. In other words, this implementation of a private, permissionless blockchain becomes a true autonomous notary function that opens the black box.

8. ARTIFACT INSTANTIATION