1 Applicable Regulations in Digital Finance
Regulators and financial supervisory authorities have increasingly begun to worry about the increased risks posed by the rise of digital technologies/fintech. They can be characterized as risks to consumers and investors, financial services firms and financial stability. Specific actions in response to these risks have resulted in the development of international standards, implementation of very detailed and prescriptive national regulations and guidance and increased priority from supervisory authorities.
These actions cover a broad spread of areas, including technology risk, cybersecurity and operational resilience more generally, data privacy, consumer protection, firms’ governance and risk governance and amendments to anti-money laundering requirements [1].
Anzeige
The regulatory response has taken a number of forms [2]:
-
Regulatory perimeter: Some developments, such as the mainstream use of cryptocurrencies, outsourced cloud computing services and the introduction of non-financial services firms as providers of products and services such as lending to SMEs and retail payment systems, bring into question where the boundary of the regulatory perimeter should be. As the network widens, an increasing number of firms will find themselves subject to regulatory requirements.
-
Retail conduct: For consumer protection, regulators are using a mixture of (a) transparency and disclosure, (b) prohibiting or limiting the sale of some products and services to retail customers and (c) adapting codes of conduct to consider fintech developments.
-
Data and artificial intelligence: Data protection legislation, including the EU General Data Protection Regulation (GDPR), already covers most issues arising from the use of digital technologies. However, rapid change resulting from the use of artificial intelligence (AI) and distributed ledger technologies means further regulation on the collection, management and use of data may be needed. The increased data gathering activities of broad ranges (of financial and non-financial data), and the sharing of such data between a growing pool of organizations, have intensified the debate on which further regulatory control may be required.
-
Governance: Regulators are seeking to ensure that boards and senior managers have complete awareness and understanding of the digital technologies and applications used, and of the risks resulting from them, aiming to increase the focus on risk management and accountability.
-
Cybersecurity: The focus from regulators is on enforcing the implementation of existing international standards.
-
Open banking: Regulation has managed the creation of a market for new fintechs in open banking by establishing the principles and protocols on which data can be shared between different parties, usually through an application programming interface (API).
2 Main Digital Finance Regulations
Banks, fintechs and other financial organizations must consider and comply with several regulations, including general purpose regulations and regulations specific to the finance sector. The following paragraphs provide an overview of popular regulations, including their impact.
2.1 The General Data Protection Regulation (GDPR)
GDPR is a regulatory framework aimed at providing the means by which citizens can have control over their personal data. Organizations must make sure that:
Anzeige
-
Personal data is gathered legally with the appropriate consent and declarations.
-
Collected data is not misused or exploited for purposes other than for which it was collected.
-
Rights of the data owner(s) are respected in line with the controls as set out in the regulation.
The regulation relates specifically from the perspective of the H2020 INFINITECH project to the processing of ‘personal data’, meaning:
-
any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. [3]
Processing within this context means ‘any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movement’ [4].
Data collection is directly impacted by GDPR. Fintechs need to have the procedures, policies and mechanisms in place to demonstrate that their technologies and services are compliant with the GDPR. This means keeping integrity and making sure they have valid and proper consent for the customer’s data they hold, share, use and process.
Compliance breeches can result in financial penalties ranging between 2% and 4% of global turnover depending on the severity and impact of the breech. The use of technologies like blockchain requires considerable oversight to make sure that the way it is used and deployed still facilitates a core principle of GDPR, being the ‘right to be forgotten’.
Other important aspects that should be considered is the need to understand data flows within systems and applications as these days most financial applications do not sit in silos – client data passes to and from multiple systems.
Finally, pseudonymization rules are critical to make sure that data access is only ever on the basis of the ‘need-to-know’ principles [5].
3 The Market in Financial Instruments Directive II (MIFIDII)
MIFID II is focused on all financial instruments and covers services including advice, brokerage, dealing, storage and financial analysis. The directive tries to harmonize oversight and governance across the industry within all EU member states.
It has introduced more stringent reporting requirements and tests to ensure transparency and to crack down on the use of ‘dark pools’ (mechanisms by which trading takes place without identities of individuals or organizations involved being revealed). The amount of trading that can be done using ‘dark pools’ is as a result now limited to 8% of the overall trading in any 12-month period.
Algorithms used for automated trading under the directive now need to be registered with the applicable regulator(s), rigorously tested, and circuit breakers must be in place.
MIFID II also seeks to increase transparency around the cost of services. In so doing, limitations are set up on the payments made to investment firms or advisors by third parties for services that they have or are providing to clients in return. Charges for different services can no longer be aggregated into a single fee. More detailed reporting is required from brokers on the trades they carry out. Storage of all communications is recommended, thereby providing a clear audit trail of all activities [6].
MIFID II impacts digital finance technology development and deployment in the following way:
-
Data storage, aggregation and analytical requirements: All information related to trades must be retained. A data retention and archiving strategy is required to support the likely volumes of data and information.
-
Integration between disparate applications: Integration of applications with trading platforms so that key data can flow through becomes a key requirement resulting from MIFID II. API-based integration is seen as the most efficient approach in most cases.
-
Enhanced and transparent client portal: In order to provide the appropriate protection to investors, it is a requirement to maintain comprehensive client classification and client data inventories.
-
Mobile device management (MDM) strategy: This relates to the need to maintain a record of all telephone calls and electronic communications. The MDM strategy should ensure that the appropriate technology is in place to facilitate this and also restrict the use of mediums of communication such as social media where communications are encrypted, thereby making compliance difficult [7].
Alongside data retention, security and integrity of data are also critical and could pose a challenge. Appropriate mechanisms to support access control including the use of multifactor authentication should be in place.
Monitoring and audit trails of data throughout the data’s operational lifecycle are also critical to keep integrity. Regular audits should be put in place to make sure all controls, policies and procedures are being followed.
3.1 Payment Services Directive 2 (PSD2)
PSD2 [8] seeks to strengthen the regulations governing online payments within the EU. At its core is the aim of developing a more integrated and seamless payment approach across all the member states of the EU.
A key requirement of the directive is the use of strong customer authentication (SCA). The objective is to improve the levels of security around payments and to reduce fraud.
It updates PSD1 (adopted in 2007) and, as in SD1:
-
Opens the payment market to new entrants which until now had been limited to those institutions with a banking license.
-
Transparency over services offered and the resulting fees that will be incurred has been improved. This also covers both maximum execution times and exchange rates. Development of the Single Euro Payments Area (SEPA) to ease the execution of payments has been accelerated as a result of the directive.
PSD2 has a strong impact on the whole financial services ecosystem and the entire infrastructure behind payments. Furthermore, it has impact on all businesses that are making use of payment data to better serve their customers.
Security requirements are introduced for both the initiation and processing of all electronic payments alongside the continued need to protect data belonging to customers (including specific financial data). Third-party providers also fall under the remit of PSD2, including all providers who have the right to access and/or aggregate accounts and provide payment services. In essence, PSD2 is designed to give all customers access to their own data and to support greater levels of innovation and resulting competition by encouraging the incumbent banks to engage in secure customer data exchange with third parties. It should open the market for organizations in other verticals to access data with their customers’ prior consent as long as the appropriate controls are in place.
3.2 PSD II Security Requirements/Guidelines
PSD2 maintains the need for strong customer authentication (SCA), secured communication, risk management and transaction risk analysis (TRA).
In the endeavour of increasing protection for the consumer, the directive makes a requirement for banks to implement multifactor authentication for all transactions performed by any channel.
This requirement means making use of two of the following three features:
-
Knowledge: information that the customer should only know such as a password, pin code, or a personal ID number
-
Possession: an artefact that only the customer has such as a smart card or a mobile handset
-
Inherence: the relation of an attribute to its subject, e.g. a fingerprint
The elements used need to be mutually independent so that a breach of one cannot inherently mean a breach of any of the others.
Payment service providers (PSPs), as a result of the directive, will need to establish a framework implementing the required mitigation measures. In addition, controls to effectively manage all operational and security risks with respect to services they provide should be implemented. These controls formally come under the remit of the directive. These measures should include, at least:
-
The maintenance of an inventory of all business functions, roles and processes, thereby making it possible to map functions, roles and processes and to understand their interdependencies.
-
Maintain an inventory of information assets, infrastructure and the interconnection with other systems (both internal and external) so that all assets critical to the core business functions are effectively managed minimizing disruption.
-
Regularly monitor threats and vulnerabilities to assets critical to the effective delivery of business functions and processes.
3.3 4th Anti-money Laundering (AMLD4)
AMLD4 [9] is designed to ensure that accountability of companies is increased with respect to any connections that can be attributable to money laundering and/or terrorist financing. Failure to comply can bring both sanctions and reputational damage. Whilst the directive is targeted essentially at banks and other financial institutions, all corporations need to have the appropriate measures and controls in place to maintain compliance.
AMLD4 catches more business types than AMLD3. Gambling institutions; real estate letting companies, individuals or companies making single transactions over €10,000; virtual exchange currency platforms; and foreign and domestic politically exposed persons (PEPs) come under the scope of the directive.
The directive requires companies to be more aware of all risk factors when assessing business activities and functions. Some of the key risks include the following: (1) Check before engaging in business dealings that owners or people of significant control (PSC) are not PEPs (politically exposed persons). (2) Make more rigorous checks when dealing with business sectors where there is excessive cash. Such industries are known to be key targets of money launderers. (3) Make more rigorous checks when there is a connection with or when dealing with high-risk sectors. This covers sectors like construction, pharmaceuticals, arms, extractive industries and public procurement. (4) Check reputable credible media sources for any allegations of ‘criminality of terrorism’. (5) Investigate into any potential risk of dealings with an organization or an individual who may have a record of frozen assets. (6) Business ownership and control should be clear – if there are any suspicions, complexities or lack of transparency in the structure of ownership, then a thorough investigation should be instigated. Proposed business partners should be a ‘legal person’. (7) Doubts over identity of a beneficial owner should be further investigated. (8) Income and other sources of wealth for any potential partners should be clearly traceable back to their origin. (9) Increased scrutiny and investigation should be undertaken when dealing with companies who have, or are suspected of having, ties to countries that appear on the sanctions list.
Moreover, according to AMLD4, companies working in high-risk countries should be placed under increased scrutiny, and they should undergo a more rigorous set of checks. The Financial Action Task Force (FATF) releases a list three times a year which details the qualifying countries. Disclosure: Jurisdictions are increasingly encouraged to disclose organizations who continue to break the rules and/or break regulatory frameworks.
Also, AMLD4 imposes a need for identification, closer scrutiny and increased monitoring of people who are beneficial owners of companies. This can be determined by their shareholding in the business or if they are a PSC. With this in mind, a national register linked to other national registers should be kept so that anyone who needs it can see and access the required information. Compliance professionals as a result need to be able to decide what risk a company that they are working with poses before they go on to investigate their beneficial owners. National registers not being up to date is no excuse for non-compliance.
3.4 Basel IV
Basel IV focuses on operational risk management within the context of capital savings. Whilst it is not a direct stipulation, there is a recommendation that supervisory authorities should still maintain a strong focus on making operational risk improvements through strengthening operational resilience. This entails making sure that critical functions within banks are able to continue to operate through any periods of recovery or stress. This incorporates effective management of cyber risks and requires business continuity plans that are regularly reviewed and tested.
3.5 EU Legislative Proposal on Markets in Crypto-Assets (MiCA)
MiCA is being developed to streamline distributed ledger technology (DLT) and virtual asset regulation in the European Union (EU) whilst still keeping strong protection for both users and investors. MiCA aims to supply a single harmonized, consistent framework for the issuance and trading of crypto tokens [10].
The proposal has four broad objectives:
-
Legal certainty for crypto-assets not covered by existing EU legislation.
-
Uniform rules for crypto-asset service providers and issuers.
-
Replace existing national frameworks applicable to crypto-assets not covered by existing EU legislation.
-
Establish rules for ‘stablecoins’, including when these are e-money.
3.6 EU Draft Digital Operational Resilience Act (DORA)
DORA aims to set up clear foundation for EU regulators and supervisors to expand their focus to make sure that financial institutions can maintain resilient operations through a severe operational disruption.
The main reforms include [11]:
-
Bringing ‘critical ICT (Information and Communication Technology) third-party providers’ (CTPPs), including cloud service providers (CSPs), within the regulatory perimeter. The European Supervisory Authorities would have mechanisms to request information, conduct off-site and on-site inspections, issue recommendations and requests and impose fines in certain circumstances.
-
EU-wide standards for digital operational resilience testing.
-
Creating consistency in ICT risk management rules across financial services sectors, based on existing guidelines.
-
Consistency in ICT incident classification and reporting.
-
Future potential for a single EU hub for major ICT-related incident reporting by financial institutions.
3.7 EU Draft AI Act
Under the AI Act, a number of AI practices will be forbidden. AI which makes use of subliminal components or exploits human vulnerabilities to distort a person’s behaviour in a harmful way will be forbidden. In addition, social scoring systems and real-time remote biometric identification systems are not allowed.
The AI act includes a list of high-risk AI systems, including those systems that could result in adverse outcome to health and safety of persons, and stand-alone AI systems which may pose a threat to the fundamental rights of persons. Before a high-risk AI system is put on the market or deployed to service, it must undergo a conformity assessment procedure. Once completed, the system will have to be labelled with a CE marking. Certain high-risk AI systems should be also registered in an EU database maintained by the Commission.
ICT systems can only be placed on the EU market or put into service if they comply with strict mandatory requirements, in particular [12]:
-
Establish a risk management system.
-
Maintain clear quality criteria for the datasets used for training and testing of those systems.
-
Design of high-risk AI systems should enable them to automatically log events whilst the system is operating.
-
Operation of the high-risk AI systems must be sufficiently transparent to allow the users to interpret the system’s output and use it appropriately.
-
Systems must come with instructions.
-
High-risk AI systems must be designed to enable humans to oversee them effectively, including understanding the capacities and limitations of the AI.
-
Oversight features allowing users to override the decisions of the AI or to interrupt the system by means of a ‘stop’ button.
-
Design and develop in such a way that they achieve, in the light of their intended purpose, an appropriate level of accuracy, robustness and cybersecurity, perform consistently in those respects throughout their lifecycle and are resilient, in particular against errors, inconsistency of the operating environment and malicious actors.
4 Supporting Technologies for Regulations in Digital Finance
Focusing on financial and insurance sectors, the INFINITECH project contributes supplying technologies that help to fulfil the regulations exposed in the previous section. Given the number of pilots that are being conducted, a large number of technologies that provide solutions for this sector are being developed by INFINITECH partners.
Among the technologies provided in INFINITECH, this chapter exposes those that help fulfilling the regulations in digital finance. The list of INFINTIECH technologies is provided in Table 1, which is based on INFINITECH’s work on regulatory compliance tools [13]:
Table 1
INFINITECH technologies for regulatory support
Name tool/platform | Relevance and applications for regulatory compliance |
|---|---|
Data Protection Orchestrator (DPO) (Atos (https://atos.net) is the provider of this technology) | It allows embedding of automating tools for assessing security and privacy by design and by default in business flows, these being heterogeneous and complex. It orchestrates various privacy and security management functions (such as access control, encryption and anonymization) |
Digital User Onboarding System (DUOS) (Atos (https://atos.net) is the provider of this technology)
| This solution allows management of virtual identities in a mobile device. It makes use of electronic ID (eID) or passport for remote user registration |
DUOS uses eIDs issued by European national authorities according to the EU eID schemas: eID cards and passports | |
In order to integrate DUOS, it is necessary to adapt and customize it for a user’s context of need (e.g., bank application) that requires user authentication | |
This technology could be used in digital finance to implement ‘anonymous’ user onboarding. The user can be securely identified by eID or e-Passport without revealing any detail about his/her identity to a third party | |
Botakis Chatbot Development Network (Crowd Policy (https://crowdpolicy.com) is the provider of this technology)
| A tool for rapid development of chatbot applications, which can be used for the development of chatbot’s features in digital finance |
Botakis Chatbot Platform is expected to be enhanced in this way: | |
Built-in dialogs that utilize and are integrated with existing natural language processing (NLP) frameworks (open or proprietary) provided by partners or every interested party | |
Powerful dialog system with dialogs that are isolated and composable | |
Built-in prompts for simple actions like yes/no, strings, numbers or enumerations [14] | |
As part of the available chatbot functionality, it will be possible to include GDPR consent and manage requests from people exercising the right to be informed, the right of access, the right to rectification, the right to erasure, the right to restrict processing, the right to data portability and the right to object | |
Crowdpolicy Open (innovation) banking solution (Crowd Policy (https://crowdpolicy.com) is the provider of this technology)
| ‘Crowdpolicy Open (innovation) banking platform is a set of predefined and customizable banking web services and data models integrated with our own API Manager that supports access control, monitoring and authentication. This solution puts the bank (or any monetary financial institution) in control of the third-party partner relation’ [14] |
Crowdpolicy Open (innovation) banking platform mainly covers the requirements for open banking APIs as part of the PSD2 directive, which has several modules that also are API-based |
Table 1
Anonymization tool (Gradiant (https://gradiant.org) is the provider of this technology) | ‘The anonymization tool is based on a risk-based approach that modifies data in order to preserve privacy. The tool includes different anonymization algorithms and it will determine automatically which of them (generalization, randomization, deletion, etc.) should be applied in order to preserve the maximum level of privacy for the data. It also includes a set of privacy and utility metrics that allow to measure the risk that remains after anonymizing the dataset, and the impact of the anonymization process on the quality of the data. |
The component requires two inputs: the data that has to be anonymized and a configuration file that defines the structure of the data, its location and the privacy requirements’ [14] | |
The anonymization tool is intended to be used in two modes, batch or streaming. In the case of using it in batch mode, the output of the component (anonymized data) is stored in a database. The location of the database has to be known beforehand (through the configuration file that is taken as an input). If the streaming mode is used, the output will be the queue of the service | |
Blockchain-enabled Consent Management System (Ubitech Limited (https://ubitech.eu), IBM (https://il.ibm.com) and Innov-Acts Limited (https://innov-acts.com) are the providers of this technology) | The blockchain-enabled Consent Management System offers a decentralized and robust consent management mechanism that enables the sharing of the customer’s consent to exchange and utilize their customer data across different banking institutions. The solution enables the financial institutions to effectively manage and share their customer’s consents in a transparent and unambiguous manner. It is capable of storing the consents and their complete update history with complete consents’ versioning in a secure and trusted manner. The integrity of customer data processing consents and their immutable versioning control are protected by the blockchain infrastructure [15] |
To achieve this, the solution exploits the key characteristics of blockchain technology to overcome the underlying challenges of trust improvement, capitalizing on its decentralized nature and immutability due to the impossibility of ledger falsification. The usage of blockchain enables extensibility, scalability, confidentiality, flexibility and resilience to attacks or misuse, guaranteeing the integrity, transparency and trustworthiness of the underlying data [15] |
Taking regulations of digital finance exposed in the first section of this chapter and the mentioned technologies that help to fulfil the regulations, a mapping between regulations and technologies has been performed. Table 2 shows the technologies that can be deployed to address different regulations applicable to digital finance.
Table 2
INFINITECH regulatory support tools
Regulation | Regulatory compliance need | Technology applied |
|---|---|---|
GDPR
| Consent management: set of tools that allow the data subject what data they permit to share | Botakis Chatbot Development Network |
Privacy dashboards | ||
CMS (Content Management System) for storing digitized documents | ||
Blockchain-enabled Consent Management System | ||
Anonymized data: dataset in which it has removed personally identifiable information, in an irreversible way | Anonymization tool | |
ICARUS | ||
Pseudonymized data: dataset in which the fields within a data record are replaced by one or more artificial identifiers or pseudonyms; this makes the data less identifiable whilst remaining suitable for data analysis and data processing | Pseudonymization tool | |
MIFID II | Recording and auditing system: allows the review and evaluation of computer systems and processes that are running, as well as their use, security and privacy whilst processing information. It provides security and adequate decision-making | Ad hoc logging implementations |
PSD II | Online payment services meeting the regulations | CrowdPolicy Open banking solution |
SIEM | ||
AMLD4 | Inclusion on local databases of PEPs | Ad hoc solutions for each country |
General
| Authentication: the process of identifying a user or process, proving that they are valid or genuine | Specific solutions |
CrowdPolicy Open solution | ||
DUOS for Digital User Onboarding | ||
Authorization: the process of specifying access rights to use resources | Specific solutions | |
CrowdPolicy Open solution | ||
Identity and access management | ||
Privacy and security services orchestration: execution of processes involved in creating a service that provides compliance with regulations | Data Protection Orchestrator |
5 Regulatory Compliance Tool and Data Protection Orchestrator (DPO)
A regulatory compliance tool is a set of software components that provides added functionalities needed to comply with the regulations applicable to a particular use case [13].
A common situation is the implementation of regulatory compliance mechanisms on existent tools and solutions: when the need for regulatory compliance is identified on existing tools, implementation of additional security, privacy and data protection mechanisms is challenging and usually requires a complete redesign of the solution. INFINITECH proposes a general regulatory compliance tool based on the Data Protection Orchestrator (DPO) [16] introduced previously on this chapter. The DPO has been designed in WITDOM Project [17] and will be demonstrated in INFINITECH. The DPO can be customized and applied to multiple use cases, providing the needed protection, security and privacy mechanisms for regulatory compliance.
The main goal of the DPO is to coordinate the invocation of components that implement privacy, security or data protection techniques, as well as other external services, in order to provide a suitable privacy, security and data protection level (specified by a secure service provider compliant to regulations).
The Data Protection Orchestrator uses the Business Process Model and Notation 2 (BPMN2) format. The business process guides and establishes all the steps in the adequate order that have to happen to ensure the security, privacy and data protection required for a particular use case.
The use of the Data Protection Orchestrator provides the following benefits:
-
Helps secure service developers and protection component’s providers to ease the provision of the process for protection configurations
-
Allows the combination of individual privacy, security or data protection components creating complex protection processes
-
Supplies the needed business logic to ensure that regulations are fulfilled
-
BPMN diagrams can be visually exposed, providing a clear view of the protection process
6 Conclusions
The development of digital finance applications and financial technology must comply with the rich set of regulations that are applicable to the finance sector. Regulatory compliance is mandatory for launching novel data-intensive applications in the market. As such, it is also a key prerequisite for the development and deployment of big data and AI applications, such as the ones presented in earlier chapter in the book. To facilitate regulatory compliance, the INFINITECH project has developed a rich set of tools, which help financial organizations to address the mandates of the various regulations. These tools aim at lowering the effort and costs of regulatory compliance for financial institutions and fintechs.
Acknowledgments
The research leading to the results presented in this chapter has received funding from the European Union’s funded Project INFINITECH under Grant Agreement No. 856632.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.