6.1 Legal and System Design Evaluation
To assess the rigor of the developed prototype, we conducted two types of assessments, on the one hand one regarding legal requirements and, on the other, a system design check. Whereas the first serves as a tool to ensure that all relevant legal requirements are considered, meaning that the developed KYC/ICO-system uses the right regulations as input, the latter ensures that the system is technically feasible and compliant-by-design. The consultations with lawyers were not audio-recorded due to legal reasons, therefore the reported feedback described in the following is based on conversation notes.
The first round of the legal requirements check was conducted during two 1-h consultations each with a lawyer experienced in the conduct of ICOs, including necessary KYC-processes which were identified through an Internet search. After having outlined the objectives of our prototype, we explained the process with which we had identified regulations and the resulting set of legal requirements and objectives. We asked the lawyer for an assessment concerning whether or not the identified regulations were appropriate and complete given the legal situation. During the consultation, it was pointed out that given the preliminary information provided by the BaFin, a final statement on the completeness of regulations can only be made for the time being. Additionally, it became evident that potential violations of the GDPR may arise due to the implementation of AML-regulations, especially the increased due diligence requirements. This insight triggered the renewed start of the requirement search focusing on GDPR and related regulations. Using forward search, relevant requirements related to the privacy of ICO participants were identified and subsequently translated into design objectives, leading us to the final set of ten objectives presented previously (Table
1). The second consultation with the lawyer in the first evaluation round led to minor linguistic adaptations as well as to the approval of the completeness of privacy-related legal requirements.
We conducted a second round of evaluation focusing on the legal requirements by approaching two additional lawyers as recommended by the first lawyer. We conducted separate interviews which lasted 1 h and 0,5 h respectively, again explaining the KYC/ICO-system and asking for their assessment concerning the completeness and appropriateness of the identified regulations. While both lawyers agreed on the completeness and appropriateness of the identified regulations and design objectives, one lawyer stressed the provisional nature of these findings. In particular, the lawyer stressed that it is essential to have the possibility of adapting rules, and thus smart contracts, fast and conveniently as the legal situation can change quickly. Moreover, it was discussed that, at the moment, the prototype is only compliant-by-design for the European and mainly the German legal area.
Including these objections in the technical evaluation, we performed two rounds of system design evaluation by IT-experts, the description of which can be found in Table
5. These experts were not previously involved in the construction of the artifact (Frank
2007) and had considerable experience in designing identity solutions in the context of KYC-systems. The experts were identified using snowball sampling, i.e., we used recommendations from each of the identified experts, with the supporting Tech-startup recommending the first expert. While we are aware that this method could lead to biases in some cases, it was deemed appropriate given the few IT-experts who possess a comprehensive understanding of both the conduct of ICOs and KYC-processes.
Table 5
Descriptive characteristics of IT-experts
1 | Engineer | C-level manager | 13 | 1 |
Computer Scientist | C-level manager | 4 | 2 |
Computer scientist | Software Lead developer | 12 | 4 |
2 | Engineer | Software engineer | 6 | 1 |
Computer scientist | Software developer | 3 | 1 |
We explained the KYC/ICO-system objectives as well as graphical representations (i.e., the high-level architecture, sequence diagram, and the interface) to the experts, asking for their assessment. We conducted semi-structured interviews that were audio-recorded, transcribed, and coded subsequently (Wolfswinkel et al.
2013). Importantly, we informed the experts that we seek honest expert evaluation which provides us with advice on how to improve the prototype.
The results of the system design evaluation are summarized in Table
6. According to the results of the evaluation, the prototype is capable of enforcing five out of ten requirements related to the identification and verification of information, process design, and KYC/ICO-process transparency. We marked automatically enforceable objectives in Table
4 using an”F,” indicating that these objectives are compliant-by-design. Partially fulfilled objectives refer to objectives and associated rules that can be technically enforced, which were however not yet sufficiently legally specified, i.e., the threshold for large funds was not specified up until the current date, or rules required the enforcement of regulations beyond the KYC/ICO-systems boundaries, e.g., the global deletion of personal data on local servers.
Table 6
Requirements and design objectives evaluation (Status (Stat.): F – fulfilled, PF – partial fulfilled, NF – not fulfilled)
Subject: Identification and verifying information |
1. | F | We addressed this need by linking our prototype to the German identity card and the respective backend server, i.e., base our approach on data that is verified by authorities. This approach also ensures the accuracy of the data |
2. | F | There are rare cases in which authorities do not have all the information. In this case, Objective 2 cannot be fulfilled |
3. | PF | If funds exceed a certain threshold, the eID Provider’s App requires the investor to make a statement on the source of funds or add corresponding documents. There is no legal rule what is deemed sufficient for this. Thus the emitter needs to decide whether the information is adequate or not |
Subject: data handling |
4. | NF | While the transaction as such is stored on-chain, information on the emitter or investor is not. Enriching the KYC-process with additional information is an implementation task for the emitter, who is expected to have an off-chain document management system |
5. | NF | Currently, the prototype does not provide data processing. From a technical viewpoint, however, the implementation of permissions to modify personal data can be easily implemented |
6. | PF | An investor can ask the KYC-provider and ICO emitter to delete personal data after the five-year storage obligation has expired. Automated enforcement mechanisms cannot be implemented. Transaction-related information cannot be deleted without significant expenditure |
Subject: investors privacy and KYC/ICO-process transparency |
7. | NF | No technical solution is available yet that prevents the privacy violations – possible solutions are currently in the development phase, but not applicable to web services, see, for example, Khalilov et al. ( 2018). GDPR prevents the KYC-provider and ICO emitter from tracking future investments. The investor can implement precautions, e.g., use token mixers or different storing wallets |
8. | F | Investors can quickly inform themselves about the status of the KYC and investment process using the app. The completion of the KYC-process is a prerequisite for the token-money swap between an investor and an emitter |
Subject: process design |
9. | F | Public/private key management is handled via the ICO investment web interface, providing a one-click solution |
10. | F | The process of downloading the eID provider’s app, scanning the QR-Code on the website of the KYC-provider, entering the PIN, attaching the identity card, and finally entering the TAN is estimated by experts to be completed in less than 10 min |
During the interviews, experts claimed that three objectives could not be enforced, e.g., we were not able to deploy the fourth legal requirement, stating that data on business relationships and transactions should be kept for a subsequent analysis for five years. Moreover, while the transaction log of blockchain makes a receipt of the token-money swap accessible, there is no mechanism implemented that stores the captured identity of approved or denied investors in order to avoid investor tracking and, especially, transaction flow analysis. Thus, a full transaction record, including not only information on the amount of money and tokens transferred but also identity-related information, is not intended due to privacy protection regulations (European Commission
2019). This issue becomes even more relevant when looking at proposed solutions to avoid transaction tracking and to protect investors' privacy. Khalilov et al. (
2018) analyze tools that strive toward improving ICO investors’ privacy based on, for instance, decryption mix-nets, fair exchange protocols, or zero-knowledge proofs, but the majority of these solutions are still in their conceptual development phase.
Also, blockchain technology typically supports only pseudo-anonymous transactions, which means that identities of the transacting parties are not known to the public. Consequently, recording investors' identities along with the funds is a task left to the ICO emitter, who is expected to implement a document management system with which he or she may support transaction analysis. The main issue here, however, is that of interoperability. Future research should thus focus on how we can create interfaces to combine blockchain and other centralized or decentralized infrastructures to maximize efficiency and cost-saving potentials of blockchain-based KYC solutions.
Lastly, our prototype ensures that the outcome of a KYC-process and information related to an individual cannot be revoked by any party other than the KYC-provider. While we stated this requirement before the development of our prototype, the implementation of these features requires a careful evaluation of possible permission structures and the development of a governance framework. While this was out of scope for this research project, IT-experts emphasized that future research needs to develop governance structures that support KYC and ICO-processes on a public blockchain while distributing permission rights in such a way that, as far as possible, no single party involved in the joint KYC/ICO-process can change data unnoticed. At the same time, the current legal situation requires that state authorities verify identities. Thus, while complete decentralization might be technically feasible (Parra Moyano and Ross
2017), the legal situation requires partial centralization, i.e., a trusted authority responsible for verifying identities and for deciding upon the success of the KYC-process. Given the current European and, in particular, German jurisprudence, the blockchain-based KYC-system proposed in this paper, consequently, allows as much decentralization as technically
and legally possible.
In our second round of the technical evaluation, we received the feedback to analyze the coding of the smart contract from a security perspective, as cases of lost funds have resulted from smart contract design issues in the past. Thus, we performed a security assessment by checking for common pitfalls in smart contract coding (Atzei et al.
2017). One of the flaws identified relates to the fact that KYC-providers map the captured identity data and the corresponding blockchain username only by trusting the saved KYC-token found in the smart contract. A malicious miner could steal the KYC-token that a user was about to enter and could himself claim this token by adding the KYC-token to the information of his investment. Then the KYC-provider would erroneously assign the captured off-chain identity data to the blockchain account of the miner instead of to the one of a legitimate investor.
We addressed this issue by adding off-chain information from the investor to the KYC-provider containing the investor username. This way, the KYC-provider can check whether the KYC-token found in the smart contract on-chain belongs to the same investor name transmitted off-chain. The on-chain information is taken into account because of the proven message authenticity by the investor. Another improvement for the coding was an added warning if a smart contract is fraudulently used to emulate an investor, which possibly leads to attacks because of limited computing resources. Furthermore, we ensured that status checks and status updates in the coding are always performed before funds or tokens are transferred to prevent reentrancy or unpredictable state attacks.
6.2 Applicability of KYC/ICO System
We assessed the relevance of the designed KYC/ICO-system, conducting an applicability test (Rosemann and Vessey
2008). We conducted 16 semi-structured interviews with potential users of the KYC/ICO-systems, focusing on ICO investors who had already experienced a KYC-verification process. Our interview partners were mostly male (68%) and participated on average in 3 ICOs. Before the interviews started, we explained the objectives and the design of the KYC/ICO-system to participants, laying special emphasis on how they would interact and use the system once it was implemented. Doing this, we constantly made sure that the interview partner understood the basic functionalities and the objectives of the designed KYC/ICO-system. During the interviews, we asked participants whether the designed KYC/ICO-system is
important, i.e., tackles key issues when investing via ICOs, whether it addresses a real-world problem, and if it is timely (Rosemann and Vessey
2008). Second, we evaluated whether the designed solution is
accessible, i.e., whether the design is understandable and outcomes, e.g., the user interface, are perceived as usable. Third, we asked for the assessment of the prototype’s
suitability, i.e., whether the designed KYC/ICO-system is perceived to be a solution to the problem at hand. Eventually, it was emphasized that there were no right or wrong answers and that the goal of the interview was to assess the relevance of the prototype from the users' perspective.
The evaluation of the interviews indicated the relevance of the developed solution from the user's perspective. 75% of the interview partners reported slow identity checks when registering on platforms or websites based on which users can trade and invest in ICOs, with the main problem being that identity checks had to be repeated several times due to technical problems leading to non-identifiability. 25% even claimed to have aborted the process, as the re-verification of the identity verification was either too time-consuming or – with 16% of the interview partners – led to distrust. 38% of the interview partners stated that they had problems connecting their trading activities with their bank account, as the bank terminated such a connection for security reasons. Overall, the majority of respondents (94%) indicated that they would use a KYC/ICO-system offered by financial organizations to verify their identity if the system solved the problems mentioned above, i.e., ensured speed and reliability of identity verification.
Potential users were less clear in terms of their assessment of the accessibility of the designed ICO/KYC-process. While 56% of the participants stated that they generally appreciated a solution based on QR codes given the ease of use with which the identity can be proofed, 13% were worried about the security of the system. While security checks must be in place, especially at interfaces ( and have to be further developed and checked when the prototype is implemented), 19% of interview partners, claimed that a solution in cooperation with eID-providers which are compliant with eIDAS regulation increase confidence in the security of the ICO/KYC-system in general. Moreover, 44% of the interview partners stated that while they generally thought that the demonstrated system seemed to be intuitive to use, they would have to use the system on their laptop or mobile phone when investing in an ICO for a final evaluation.
Lastly, we evaluated the suitability of the designed KYC/ICO-system by asking whether the designed solution was perceived to actually solve problems of ICO investors. Our interview partners were quite clear about this point, i.e., 94% claimed that the proposed system was suitable to solve identity verification issues assuming that the system works as described, i.e., that no major technical problems occur and that the implementation of identity verification works rapidly and reliably. In fact, potential users stated that they perceived the solution as especially suited as it reduced the complexity for the user, while potentially reducing the costs for KYC-processes depending on the amount of participating financial organizations. Thereby, 19% of the interview partners primarily see financial organizations in the responsibility to take care of proper KYC-verification processes, meaning that KYC-processes are demanded to be fast, reliable as well as connectable with ICO processes by integrating innovative solutions. Thus, the majority of interview partners perceived the proposed KYC/ICO-system as suitable to solve experienced issues, assuming the faultless functioning of the prototype once fully implemented.