With an increasing investment in digital assets such as cryptocurrencies, many nancial technology (FinTech) systems and custodians have become safety critical. Yet, current FinTech system development approaches often lack the rigorous safety practices found in other certi ed industries. This paper focuses on the development of goal models for analyzing a FinTech's system stakeholders, goals, and processes, as a rst step towards system certi cation. A strategic dependency model is used to identify the interfaces of the system with its context, and is enriched with an operational/process view using Use Case Maps. This goal/process combination brought much in the identi cation of stakeholders, critical resources, priorities, and appropriate safety controls.
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
This paper reports on an ongoing project that uses requirements modeling methodologies and standards that are foreign to the FinTech industry but common in other safety-critical engineering domains, in addition to current nancial regulations, to rise up to the challenge of building a digital asset custody system that will keep institutional investors' assets safe (e.g., through a set of multisignature smart contracts and wallets). Additionally, the results of safety-guided design and safety evaluations of the system should be communicated to the stakeholders in a clear and comprehensible manner to provide cost and schedule reductions in the certi cation process, and reduce dependencies on very expensive accounting rms (including the Big Four) that provide the certi cation services. 2
In North-America, the most notable certi cation applied to nancial entities is the System and Organization Controls (SOC)(https://www.aicpa.org/soc). Di erent SOC reports approach system controls from di erent perspectives, namely compliance, operations, and nancial reporting. The most relevant report on system-level and entity-level operational controls of a nancial service organization is the SOC2 report, based on the guidelines provided by the American Institute of Chartered Professional Accountants (AICPA) and CPA Canada, known as Trust Services Principles and Criteria (TSC) for Security, Availability, Processing Integrity and Con dentiality (https://bit.ly/2ZnNhgB). A new standard has also been developed for nancial service organizations that interact with digital assets: Cryptocurrency Security Standard (CCSS)(https: //cryptoconsortium.github.io/CCSS/). CCSS certi cation is deemed by auditing rms as a major stepping stone towards establishing con dence in novel blockchain-based systems.
The above standards do not name safety explicitly as a criterion. They rather use the term controls, which are essentially the tools that are imposed on the system to ensure its safety. The development process of the system must employ an approach that addresses the controls of the system, while considering all other criteria requested by the standards, e.g., availability, security, and privacy.
Systems developed in the FinTech industry have major human and software
elements, and are hence considered socio-technical systems. Goal modeling has
shown its utility when it comes to capturing intentionality of stakeholders in
such systems, while providing support for compliance, trade-o and
decisionmaking [
For a FinTech system to be successful, important stakeholders such as regulators, banks, and insurers must be on-board and be assured that their concerns are handled properly. Therefore, the results of the safety-guided design of a system to-be must be communicated to them as clearly, and yet as completely, as possible. Due to the novelty of FinTech systems being developed (e.g., involving advanced blockchain-based technologies), communication of proper artifacts, documents, and justi cations to help regulators and other stakeholders decide on the acceptable safety of systems is crucial. Although many guidelines and standards exist for general nancial systems (including SOC, TSC, and CCSS), process and product standards have not caught up to recent FinTech advancements and are not su cient to address certi cation problems.
For the above reasons, and since goal-oriented approaches are useful for
developing socio-technical systems, we propose to enhance traditional
(prescriptive) approaches with a normative (goal-oriented) view [
The rst step in modeling the goals of a FinTech system is to gain a holistic understanding of all the stakeholders and their dependencies. They can often be categorized into four major expertise domains: governance and policy, regulatory and compliance, business and operations, and technical (engineering).
The stakeholders, with varied expertise in the above domains, have unequal understanding of the core of the system. In an onion model, we nd them in various layers from the core operational layer, to the system layer (containing the management and support elements), and then to the environment layer: { System Operations: Normal Operators (Finance Manager and Technical Users), Maintenance Ops (Hardware, Software), Operational Support (Transaction Mining, Customer Support), Interfacing System (Cloud, Internal Network). { System: Internal Consultants (Compliance O cer), Client (Investors, Management), Functional Bene ciary (Institutional Funds). { System Environment: Customer (White-label Partners), Interfacing System (Crypto-exchanges, Blockchains Platforms, Insurers), Regulators (Securities, Judiciary, Tax and KYC/AML3 Authorities, Non-statutory Regulators including standards, consortia, and Self-Regulatory Organizations), Negative Actors (Competitor, Hacker), External Consultants (Business Auditor, Security Specialist, Legal Counsel).
This view is employed in the early stages of the system development to draft the Concept of Operations (ConOps) of the system. Adding a development viewpoint to the ConOps view would require the list of stakeholders to be augmented with, e.g., project managers and system developers. The system development 3 Know Your Client (KYC) and Anti-Money Laundering (AML) e orts are crucial in the nancial industry. team is present in all three layers of the system and has interactions with virtually all other stakeholders (except negative actors such as hackers).
Various sources of information such as handbooks, standards, and interviews with stakeholders and decision makers will uncover valuable dependencies. These dependencies will in turn become the basis for sketching a strategic dependency model of the system, which starts by outlining the actors and their directional dependencies, hence enabling the elicitation of the actors' goals. In GRL, the source and target of a dependency are intentional elements from di erent actors.
A slice of the strategic dependency model is provided in Fig. 1, illustrating how three actors, namely the Underwriter, the Securities Regulator, and the Judiciary, depend on the system's goal Report to produce the Security Report and on the Auditor's ability to perform veri cation (Verify). Multiple dependency inbound and outbound links are a shorthand for a distributive dependency relationship, i.e. there are 6 dependency relationships that have Security Report as their dependum. Here, the Brane actor is the DA custodian and service provider.
The creation of the GRL model has allowed the organization to discover critical resources, i.e., resources that have a high number of dependencies which, if not realized properly, would result in the simultaneous dissatisfaction of multiple stakeholders. Thus, the requirements elicitation, system development/testing, and certi cation e orts can be prioritized in accordance with the criticality of the dependums and the system goals that provide them.
As explained in Section 2, the main concern of nancial regulators is the controls on systems operations. To analyze the operational aspect of the system, the GRL model is expanded by de ning Use Case Map processes for functional goals of the system. A process model of the Perform Due Diligence system goal is provided in Fig. 2. The UCM model allows for analysis of the business process. The operationalization of goal Perform Due Diligence starts by the activity Evaluate Jurisdiction, which is the responsibility of the service provider (Brane) and yield one of two possible outcomes (illustrated by an OR-fork), i.e., being of low or high risk (the latter leading to the rejection of the client).
Performing the operational analysis, has allowed the organization to check the controls it has in place, assess alternative ones, provide a means to demonstrate compliance to the regulators, and have a basis for the analysis of systemic safety.
Our complete URN model of the FinTech's digital asset management system, developed with the jUCMNav tool, is composed of 15 actors, 100 intentional elements, and 96 intentional links for the GRL view, and of 5 components, 84 responsibilities, and 22 interconnected process maps with up to 7 levels of nesting through stubs for the UCM view. 4
With the emergence of Distributed Ledger Technologies, the new FinTech certication landscape has become hard to navigate, both for service providers and regulators. A service provider not only bears the responsibility of developing an e cient system addressing many stakeholders concerns, but also of conveying its design rationale and safety analysis to regulators that provides justi ed assurance. Assurance cases can easily be misused if their authors do not focus on discovering the system risks or form arguments that enforce con rmation bias.
The rst step towards a goal-based approach in acquiring certi cation for FinTech systems starts with the analysis of stakeholders, their interfaces, and the system-level operations of the system. The stakeholders were identi ed based on an onion model, while their interfaces with the service provider were studied via the creation of a strategic dependency goal model. This has aided the service provider in discovering critical resources, the system goals providing them, and the stakeholders' goals depending on them. This also enabled a better prioritization of development e orts while increasing system e ectiveness. The system goals were expanded with a UCM process view, enabling the analysis of the current controls and acting as a stepping stone towards systemic safety analysis.
The development process of FinTech systems should be improved by
implementing systemic safety analysis approaches such as STPA [
The results of the a safety-based design should then be clearly communicated
to the regulators. Assurance cases describe the argumentation on system
properties in a structured manner. Although many notations and tools have been
provided in order to create structured assurance arguments [