Compression and Understanding of Industrial Data

Draft Standard Table of Contents – Use Cases and Functional RequirementsFramework LicenceCall for TechnologiesTemplate for responses to the Call for TechnologiesApplication Note

Draft Table of Contents of Standard

1       Introduction. 1

2       Scope of standard. 1

3       Terms and definitions. 1

4       Normative references. 2

5       Use Case Architecture. 2

5.1       AI-based Performance Prediction. 2

6       AI modules. 3

6.1       AI-based Performance Prediction. 3

6.1.1       Governance data (raw) 4

6.1.2       Financial statement data (raw) 4

6.1.3       Risk assessment technical data (raw) 4

6.1.4       Governance. 4

6.1.5       Financial statement 4

6.1.6       Risk assessment technical data. 4

6.1.7       Financial features. 4

6.1.8       Severity. 4

6.1.9       Decision Tree. 4

6.1.10     Default probability. 5

6.1.11     Business continuity index. 5

7       References. 5

 

 

1        Introduction

2        Scope of standard

3        Terms and definitions

Table 6 – MPAI-CUI terms

 

Term   Definition
Access Static or slowly changing data that are required by an application such as domain knowledge data, data models, etc.
AI Framework AIF The environment where AIM-based workflows are executed.
AI Module AIM The basic processing elements receiving processing specific inputs and producing processing specific outputs.
Communication The infrastructure that connects the Components of an AIF.
Data Processing DP A legacy technology that may be used to implement AIMs.
Decision Tree A decision support tool that uses a tree-like model of decision, given the financial and governance features.
Delivery An AIM that wraps data for transport.
Execution The environment in which AIM workflows are executed. It receives exter­nal inputs and produces the requested outputs both of which are application specific.
Financial features A set of indexes and ratios computed using financial statement data.
Financial statement Data produced based on a set of accounting principles driving maintenance and reporting of company accounts, so that financial statements can be consistent, transparent, and comparable across companies.
Governance features A set of indexes/parameters that are used to assess the adequacy of the organizational model.
Knowledge Base Structured and unstructured information made accessible to AIM (especially DP-based).
Management and Control Manages and controls the AIMs in the AIF, so that they execute in the correct order and at the time when they are needed.
Risk assessment Attributes that indicate the internal assessment that the company performs to identify and measure potential or existing vertical risks, and their impact on business continuity.
Severity A set of values, each reflecting the level of risk for that specific vertical risk as evaluated by the company.
Storage Storage used to e.g., store the inputs and outputs of the individual AIMs, data from the AIM’s state and intermediary results, shared data among AIMs.

4        Normative references

  1. International Financial Reporting Standard. List of IFRS Standards. Available online: https://www.ifrs.org/issued-standards/list-of-standards/
  2. International Organization for Standardization. ISO 37000 Guidance for the Governance of Organizations. Available online: https://committee.iso.org/sites/tc309/home/projects/ongoing/ongoing-1.html
  3. International Organization for Standardization. ISO 31000 Risk Management. Available online: https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100426.pdf
  4. International Organization for Standardization. ISO 27005 Information technology — Security techniques — Information security risk management

5        Use Case Architecture

5.1       AI-based Performance Prediction

A company may need to access the flow of internal (i.e., financial and governance data) and exter­nal data related to the activity of the company to assess and mon­itor its financial and organizational performance, as well as the impact of vertical risks (e.g., cyber, seismic, etc.), according to the current standards (e.g., ISO 31000 on risk assessment and management). The current version of MPAI-CUI takes into account only cyber and seismic risks that have an impact on financial per­formance. Other risks will be considered in future versions of the standard.

MPAI-CUI may be used by:

  1. The company generating the data flow to perform compression and understanding of the data for its own needs (e.g., to identify core and non-core data), to analyse its financial performance, identifying possible clues to a crisis or risk of bankruptcy years in advance. It may help the board of directors and decision-makers to make the proper decisions to avoid these situations, conduct what-if analysis, and devise efficient strategies.
  2. A financial institution that receives a request for financial help from a troubled company to access its financial and organizational data and make an AI-based assessment of that company, as well as a prediction of future performance. By having a better insight of its situation, a financial institution can make the right decision in funding or not a company.

This Use Case can be implemented as in Figure 1.

Figure 1 – Compression and understanding of Industrial Data

The AI Modules of Figure 2 perform the functions described in Table 2.

Table 2 – AI Modules of Industrial Data Compression and Understanding

AIM Function
Data Conversion Gathers data needed for the assessment from several sources (internal and external), in different formats and coverts it to a unique format (e.g., json).
Financial assessment Analyses the data generated by a company (i.e., financial statements) to assess the preliminary financial performances in the form of indexes.

Builds and extracts the financial features for the Decision tree and Pred­iction AIMs.

Governance assessment Builds and extracts the features related to the adequacy of the governance asset for the Decision tree and Pred­iction AIMs.
Risk matrix Builds the risk matrix to assess the impact of vertical risks (i.e., in this Use Case cyber and seismic).
Decision Creates the decision trees for making decisions.
Prediction Predicts values of the probability of company default in a time horizon of 36 months and of the adequacy of the organizational model.
Perturbation Perturbs the probability value of company crisis computed by Prediction, considering the impact of vertical risks on company performan­ce.

6        AI modules

6.1       AI-based Performance Prediction

The I/O data of Data Compression and Understanding AIMs are given in Table 3.

Table 3 – I/O data of Use Case AIMs 

AI Module Input Output
Data Conversion Financial statement data

Governance data

Risk assessment data

Financial statement data (converted)

Governance data (converted)

Financial assessment Financial statement data Financial features
Governance assessment Governance data Governance features
Risk matrix Technical data from internal risk assessment (i.e., cyber security) Severity
Decision Financial features, Governance features Ranking of features importance
Prediction Financial features, Governance features Probability of company crisis

Adequacy of organizational model

Perturbation Probability of company crisis (index); severity from Risk Matrix Index of business continuity

6.1.1      Governance data (raw)

6.1.2      Financial statement data (raw)

6.1.3      Risk assessment technical data (raw)

6.1.4      Governance

6.1.5      Financial statement

6.1.6      Risk assessment technical data

6.1.7      Financial features

6.1.8      Severity

6.1.9      Decision Tree

6.1.10   Default probability

6.1.11   Business continuity index

7        References


Use Cases and Functional Requirements

1        Introduction

Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI) is an international association with the mission to develop AI-enabled data coding standards. Research has shown that data coding with AI-based technologies is generally more efficient than with existing technol­ogies. Compression is a notable example of coding as is feature-based description.

The MPAI approach to developing AI data coding standards is based on the definition of standard interfaces of AI Modules (AIM). The Modules operate on input and output data with standard formats. AIMs can be combined and executed in an MPAI-specified AI-Framework according to the emerging MPAI-AIF standard being developed based on the responses to Call for MPAI-AIF Technologies [1] with associated Use Cases and Functional Requirements [2].

By exposing standard interfaces, AIMs are able to operate in an MPAI AI Framework. However, their performance may differ depending on the technologies used to implement them. Therefore, MPAI believes that competing developers striving to provide more performing proprietary still inter­operable AIMs will naturally create horizontal markets of AI solutions that build on and further promote AI innovation.

This document, titled Compression and understanding of industrial data (MPAI-CUI), contains the “AI-based Performance Prediction” Use Case and associated Functional Requirem­ents. The MPAI-CUI standard uses AI substantially to extract the most relevant information from the indus­trial data, with the aim of assessing the performance of a company and predicting the risk of bankruptcy long before it may happen.

It should be noted that the AI-based Performance Prediction Use Case will be non-normative. The internals of the AIMs will also be non-normative. However, the input and output interfaces of the AIMs whose requirements have been derived to support the Use Cases will be normative.

This document includes this Introduction and

Chapter 2 briefly introduces the AI Framework Reference Model and its six Components
Chapter 3 briefly introduces the Use Case.
Chapter 4 presents the MPAI-CUI Use Case with the following structure

1.     Reference architecture

2.     Description of AI Modules and their I/O data

3.     Technologies and Functional Requirements

4.     Interfaces of AIM I/O Data

Chapter 5 gives a basic list of relevant terms and their definition
Chapter 6 gives suggested references

Acronyms are defined in Table 1 (below). Terms are defined in a later Table 6.

Table 1 – MPAI-SPG acronyms

Acronym Meaning
AI Artificial Intelligence
AIF AI Framework
AIM AI Module
CfT Call for Technologies
DP Data Processing
ML Machine Learning

2        The MPAI AI Framework (MPAI-AIF)

Most MPAI applications considered so far can be implemented as a set of AIMs – AI, ML and, possibly, traditional DP-based units with standard interfaces assembled in suitable topol­ogies and executed in an MPAI-defined AI Frame­work to achieve the specific goal of an application. MPAI is making all efforts to identify processing modules that are re-usable and upgradable without necessarily changing the inside logic. MPAI plans on completing the development of a 1st gener­ation MPAI-AIF AI Framework in July 2021.

The MPAI-AIF Architecture is given by Figure 1.

 Figure 1 – The MPAI-AIF Architecture

MPAI-AIF is made up of 6 Components:

  1. Management and Control manages and controls the AIMs, so that they execute in the correct order and at the time when they are needed.
  2. Execution is the environment in which combinations of AIMs operate. It receives external inputs and produces the requested outputs, both of which are Use Case-specific, activates the AIMs, exposes interfaces with Management and Control and accesses Communic­ation, Storage and Access.
  3. AI Modules (AIM) are the basic processing elements receiving specific inputs and producing specific outputs.
  4. Communication is the basic infrastructure used to connect possibly remote Components and AIMs. It can be implemented, e.g., by means of a service bus.
  5. Storage encompasses traditional storage and is used to e.g., store the inputs and outputs of the individual AIMs, intermediary results data from the AIM states and data shared by AIMs.
  6. Access represents the access to static or slowly changing data that are required by the application such as domain knowledge data, data models, etc.

3        Use Cases

3.1       AI-based Performance Prediction

A company may need to access the flow of internal (i.e., financial and governance data) and exter­nal data related to the activity of the company to assess and mon­itor its financial and organizational performance, as well as the impact of vertical risks (e.g., cyber, seismic, etc.), according to the current standards (e.g., ISO 31000 on risk assessment and management). The current version of MPAI-CUI takes into account only cyber and seismic risks that have an impact on financial per­formance. Other risks will be considered in future versions of the standard.

MPAI-CUI may be used by:

  1. The company generating the data flow to perform compression and understanding of the data for its own needs (e.g., to identify core and non-core data), to analyse its financial performance, identifying possible clues to a crisis or risk of bankruptcy years in advance. It may help the board of directors and decision-makers to make the proper decisions to avoid these situations, conduct what-if analysis, and devise efficient strategies.
  2. A financial institution that receives a request for financial help from a troubled company to access its financial and organizational data and make an AI-based assessment of that company, as well as a prediction of future performance. By having a better insight of its situation, a financial institution can make the right decision in funding or not a company.

4        Functional Requirements

4.1       AI-based Performance Prediction

4.1.1      Reference architecture

This Use Case can be implemented as in Figure 2.

Figure 2 – Compression and understanding of Industrial Data

4.1.2      AI Modules and their I/O data

The AI Modules of Figure 2 perform the functions described in Table 2.

Table 2 – AI Modules of Industrial Data Compression and Understanding

AIM Function
Data Conversion Gathers data needed for the assessment from several sources (internal and external), in different formats and covert it in a unique format (e.g., json).
Financial assessment Analyses the data generated by a company (i.e., financial statements) to assess the preliminary financial performances in the form of indexes.

Builds and extracts the financial features for the Decision tree and Pred­iction AIMs.

Governance assessment Builds and extracts the features related to the adequacy of the governance asset for the Decision tree and Pred­iction AIMs.
Risk matrix Builds the risk matrix to assess the impact of vertical risks (i.e., in this Use Case cyber and seismic).
Decision Creates the decision trees for making decisions.
Prediction Predicts values of the probability of company default in a time horizon of 36 months and of the adequacy of the organizational model.
Perturbation Perturbs the probability value of company crisis computed by Prediction, considering the impact of vertical risks on company performan­ce.

4.1.3      I/O interfaces of AI Modules

The I/O data of Data Compression and Understanding AIMs are given in Table 3.

Table 3 – I/O data of Use Case AIMs

AI Module Input Output
Data Conversion Financial statement data

Governance data

Risk assessment data

Financial statement data (converted)

Governance data (converted)

Financial assessment Financial statement data Financial features
Governance assessment Governance data Governance features
Risk matrix Technical data from internal risk assessment (i.e., cyber security) Severity
Decision Financial features, Governance features Ranking of features importance
Prediction Financial features, Governance features Probability of company crisis

Adequacy of organizational model

Perturbation Probability of company crisis (index); severity from Risk Matrix Index of business continuity

4.1.4      Technologies and Functional Requirements

4.1.4.1     Governance data (raw)

By Governance data we mean attributes that indicate the governance structure of a company and of the roles of key personnel.

The most basic roles are shareholder, manager, sole administrator, president/member of the board of directors, auditor, president/member of the statutory board of directors. They can be considered as “universal”, as commonly recognized across all countries. ISO 37000 (still under develop­ment) [6] aims at proposing a consistent set of recommendations, including definitions, for organizations in terms of governance. However, a governance data ontology is missing.

To Respondents

Respondents are invited to propose a governance data ontology that captures today’s practice at the global level.

4.1.4.2     Financial statement data (raw)

The Financial statement (raw data) are produced based on a set of accounting principles driving maintenance and reporting of company accounts, so that financial statements are consistent, trans­parent, and comparable across companies.

A set of principles [3], identified by the International Accounting Standard/International Financial Reporting Standard (IAS/IFRS), can be considered as “universal”, as they are commonly recognized across all countries. Indeed, although different countries can consider different accounting principles based on their jurisdictions, they are endorsed and standardised by the IAS/IFRS to guarantee their convergence [5].

An example of a tool that provides digital representation of Financial Statement data is the eXtensible Business Reporting Language (XBRL). The requirement of any such languages is that it should reflect the balance sheet structure in terms of assets, liabilities, and shareholders’ or owners’ equity.

The Financial statement (raw data) are converted to a standard format by the Data conversion AIM.

To Respondents

Respondent are invited to propose a digital representation of Financial statements data that is applicable to a minimum set of Financial statements having a universally valid semantics. JSON and XBRLS are primary examples of such digital representations. However, other representations are possible and may be proposed.

Respondents are invited to either select one of the two choices above or suggest alternative formats. In all cases justification of a proposal is requested.

Preference will be given to formats that have been standardised or are in wide use.

4.1.4.3     Risk assessment technical data (raw)

By Risk assessment technical data, we mean attributes that indicate the internal assessment that the company performs to identify and measure potential or existing vertical risks, and their impact on business continuity.

This data contains values of likelihood, impact, gravity, residual risk and treatments. All are and are described in ISO 31000 – “Risk management — Principles and guidelines” [7].

To Respondents

Respondents are invited to propose a digital representation of Risk assessment technical data.

4.1.4.4     Governance

This is the Governance data (raw) after conversion. JSON appears to be a convenient format.

To Respondents

Respondents are requested to comment on this choice.

4.1.4.5     Financial statement

This is the Financial statement data (raw) after conversion. JSON appears to be a convenient format.

To Respondents

Respondents are requested to comment on this choice.

4.1.4.6     Risk assessment technical data

This is the Risk assessment technical data (raw) after conversion. JSON appears to be a convenient format.

To Respondents

Respondents are requested to comment on this choice.

4.1.4.7     Financial features

Financial features are a set of indexes and ratios computed using financial statement data. Examples of Financial features are given by Table 4.

 

Table 4 – Financial features

Feature Feature value Feature type
1 Absolute value Revenue/Profit
2 Index/Percentage (%) Revenue/Profit
3 Absolute value Revenue/Profit
4 Absolute value Revenue/Profit
5 Index/Percentage (%) Revenue/Profit
6 Index/Percentage (%) Cost/Debt
7 Absolute value Cost/Debt
8 Index/Percentage (%) Cost/Debt
9 Absolute value Cost/Debt
10 Index/Percentage (%) Cost/Debt
11 Absolute value Production
12 Absolute value Production
13 Index/Percentage (%) Revenue/Profit
14 Absolute value Production
15 Index/Percentage (%) Cost/Debt

 To Respondents

Respondents are requested to propose Financial features suitable for financial assessment. The Financial features should include those given by Table 4 and may also include other features that satisfy the requirement of being extracted or computed from Financial statement data.

4.1.4.8     Governance features

Governance features are a set of indexes/parameters that are used to assess the adequacy of the organizational model. Table 5 gives examples of Governance features.

Table 5 – Governance features

Feature Feature value Feature type
1 Absolute value Decision maker data
2 Index/Percentage (%) Shareholder data
3 Absolute value Shareholder data
4 Absolute value Decision maker data
5 Absolute value Decision maker data

 To Respondents

Respondents are requested to propose Governance features suitable for assessing the suitability of governance, e.g., those reported in Table 5. Proposed Governance features shall satisfy the requir­ements of:

  1. Being extracted or computed from the Governance data.
  2. Being expressed by numerical values.
  3. Adding insight to the data of Table 5.

4.1.4.9     Severity

A set of values, each reflecting the level of risk for a specific vertical risk, cyber and seismic in the phase, as evaluated by the company. This severity is computed according to ISO 27005 [8], considering the levels of probability of occurrence, business impact and gravity of a specific risk.

To Respondents

Respondents are invited to comment on this choice or to propose and motivate alternative solutions.

4.1.4.10  Decision Tree

It is a tree-like decision model, built by starting from the financial and governance features. An example is provided by [9] where the Random Forest supervised learning method has been used to predict the probability of company crisis and bankruptcy.

To Respondents

Respondents are invited to propose a decision support tool.

4.1.4.11  Default probability

It is a score in the 0 to 1 range that represents the likelihood of company default in a specified number of future months dependent on financial data. It is computed by Prediction using the fin­ancial features and decision tree.

To respondents

Respondents are requested to comment on the description above and to propose extensions.

4.1.4.12  Adequacy of organisational model

It is a score in the 0 to 1 range that represents the adequacy of the organisational model. Its value ca be used to identify potential critical points or conflicts of interest that can lead to an increase in the risk of default. It is computed by Prediction using the governance and financial features.

To respondents

Respondents are requested to comment on the description above. Suggestions about multidim­en­sional measures of adequacy are welcome.

4.1.4.13  Business continuity index

It is a score in the 0 to 1 range that represents the likelihood of company default in a specified number of months in the future dependent on financial or non-financial data. It is computed by Perturbation using default probability and severity.

To Respondents

Respondents are requested to comment on the description above and to propose extensions.

5        Terminology

Table 6 identifies and defines the terms used in the MPAI-CUI context.

 

Table 6 – MPAI-CUI terms

Term Definition
Access Static or slowly changing data that are required by an application such as domain knowledge data, data models, etc.
AI Framework (AIF) The environment where AIM-based workflows are executed.
AI Module (AIM) The basic processing elements receiving processing specific inputs and producing processing specific outputs.
Communication The infrastructure that connects the Components of an AIF.
Data Processing (DP) A legacy technology that may be used to implement AIMs.
Decision Tree A decision support tool that uses a tree-like model of decision, given the financial and governance features.
Delivery An AIM that wraps data for transport.
Execution The environment in which AIM workflows are executed. It receives exter­nal inputs and produces the requested outputs both of which are application specific.
Financial features A set of indexes and ratios computed using financial statement data.
Financial statement Data produced based on a set of accounting principles driving maintenance and reporting of company accounts, so that financial statements can be consistent, transparent, and comparable across companies.
Governance features A set of indexes/parameters that are used to assess the adequacy of the organizational model.
Knowledge Base Structured and unstructured information made accessible to AIM (especially DP-based).
Management and Control Manages and controls the AIMs in the AIF, so that they execute in the correct order and at the time when they are needed.
Risk assessment Attributes that indicate the internal assessment that the company performs to identify and measure potential or existing vertical risks, and their impact on business continuity.
Severity A set of values, each reflecting the level of risk for that specific vertical risk as evaluated by the company.
Storage Storage used to e.g., store the inputs and outputs of the individual AIMs, data from the AIM’s state and intermediary results, shared data among AIMs.

6        References

  1. MPAI-AIF Call for Technologies, MPAI N100; https://mpai.community/standards/mpai-aif/#Technologies
  2. MPAI-AIF Use Cases and Functional Requirements, MPAI N74; https://mpai.community/standards/mpai-aif/#Requirements
  3. MPAI-AIF Framework Licence, MPAI N101; https://mpai.community/standards/mpai-aif/#Licence
  4. International Financial Reporting Standard. List of IFRS Standards. Available online: https://www.ifrs.org/issued-standards/list-of-standards/
  5. European Commission. Financial reporting. Available online: https://ec.europa.eu/info/business-economy-euro/company-reporting-and-auditing/company-reporting/financial-reporting_en
  6. International Organization for Standardization. ISO 37000 Guidance for the Governance of Organizations. Available online: https://committee.iso.org/sites/tc309/home/projects/ongoing/ongoing-1.html
  7. International Organization for Standardization. ISO 31000 Risk Management. Available online: https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100426.pdf
  8. International Organization for Standardization. ISO 27005 Information technology — Security techniques — Information security risk management
  9. Perboli G., Arabnezhad E., A Machine Learning-based DSS for Mid and Long-Term Company Crisis Prediction. To be published in Expert Systems with Applications. 2021.
  10. MPAI-CUI Use Cases & Functional Requirements; MPAI N200; https://mpai.community/standards/mpai-cui/#UCFR
  11. MPAI-CUI Framework Licence, MPAI N201; https://mpai.community/standards/mpai-cui/#Licence
  12. MPAI-CUI Call for Technologies, MPAI N202; https://mpai.community/standards/mpai-cui/#Technologies

Use Cases and Functional RequirementsFramework LicenceCall for TechnologiesTemplate for responses to the Call for TechnologiesApplication Note

Framework Licence

1        Coverage

MPAI has found that the application area called “Compression and Understanding of Industrial Data” is particularly relevant for MPAI standardisation because AI allows for substantial reduction of the amount of information produced by companies and for more in-depth analysis of the data to be carried out.

Therefore, MPAI intends to develop a standard – to be called MPAI-CUI – that will provide standard technologies to implement several Use Cases, the first of which is:

  1. AI-based Performance Prediction (APP).

The MPAI Compression and Understanding of industrial data (MPAI-CUI) standard will be defined in document NNN of Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI).

2        Definitions

Term Definition
Data Any digital representation of a real or computer-generated entity, such as moving pictures, audio, point cloud, computer graphics, sensor and actu­ator. Data includes, but is not restricted to, media, manufacturing, auto­mot­ive, health and generic data.
Development Rights License to use MPAI-CUI Essential IPRs to develop Implementations
Enterprise Any commercial entity that develops or implements the MPAI-CUI standard
Essential IPR Any Proprietary Rights, (such as patents) without which it is not possible on technical (but not commercial) grounds, to make, sell, lease, otherwise dispose of, repair, use or operate Implementations without infringing those Proprietary Rights
Framework License A document, developed in compliance with the gener­ally accepted principles of competition law, which contains the conditions of use of the License without the values, e.g., currency, percent, dates etc.
Implementation A hardware and/or software reification of the MPAI-CUI standard serving the needs of a professional or consumer user directly or through a service
Implementation Rights License to reify the MPAI-CUI standard
License This Framework License to which values, e.g., currency, percent, dates etc., related to a specific Intellectual Property will be added. In this Framework License, the word License will be used as singular. However, multiple Licenses from different IPR holders may be issued
Profile A particular subset of the technologies that are used in MPAI-CUI standard and, where applicable, the classes, subsets, options and parameters relevant to the subset

3        Conditions of use of the License

  1. The License will be in compliance with generally accepted principles of competition law and the MPAI Statutes
  2. The License will cover all of Licensor’s claims to Essential IPR practiced by a Licensee of the MPAI-CUI standard.
  3. The License will cover Development Rights and Implementation Rights
  4. The License for Development and Implementation Rights, to the extent it is developed and implemented only for the purpose of evaluation or demo solutions or for technical trials, will be free of charge
  5. The License will apply to a baseline MPAI-CUI profile and to other profiles containing additional technologies
  6. Access to Essential IPRs of the MPAI-CUI standard will be granted in a non-discriminatory fashion.
  7. The scope of the License will be subject to legal, bias, ethical and moral limitations
  8. Royalties will apply to Implementations that are based on the MPAI-CUI standard
  9. Royalties will apply on a worldwide basis
  10. Royalties will apply to any Implementation, with the exclusion of the type of implementations specified in clause 4
  11. An MPAI-CUI Implementation may use other IPR to extend the MPAI-CUI Implementation or to provide additional functionalities
  12. The License may be granted free of charge for particular uses if so decided by the licensors
  13. A license free of charge for limited time and a limited amount of forfeited royalties will be granted on request
  14. A preference will be expressed on the entity that should administer the patent pool of holders of Patents Essential to the MPAI-CUI standard
  15. The total cost of the Licenses issued by IPR holders will be in line with the total cost of the Licenses for similar technologies standardised in the context of Standard Development Organisations
  16. The total cost of the Licenses will take into account the value on the market of the AI Framework technology Standardised by MPAI.

Use Cases and Functional RequirementsFramework LicenceCall for TechnologiesTemplate for responses to the Call for TechnologiesApplication Note

Call for Technologies

1       Introduction. 1

2       How to submit a response. 1

3       Evaluation Criteria and Procedure. 1

4       Expected development timeline. 1

5       References. 1

Annex A: Information Form.. 1

Annex B: Evaluation Sheet 1

Annex C: Requirements check list 1

Annex D: Technologies that may require specific testing. 1

Annex E: Mandatory text in responses. 1

1        Introduction

Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI) is an international non-profit organisation with the mission to develop standards for Artificial Intelligence (AI) enabled digital data coding and for technologies that facilitate integration of data coding components into ICT systems. With the mechanism of Framework Licences, MPAI seeks to attach clear IPR licen­sing frameworks to its standards.

MPAI has found that the application area called “Compression and Understanding of  Industrial Data” is particul­arly relevant for MPAI standardisation because AI allows for substantial reduction of the amount of information produced by companies and for more in-depth analysis of the data to be carried out.

Therefore, MPAI intends to develop a standard – to be called MPAI-CUI – that will provide standard tech­nologies to implement several Use Cases, the first of which is:

  1. AI-based Performance Prediction (APP)

This document is a Call for Technologies (CfT) that

  1. Satisfy the MPAI-CUI Functional Requirements (N200) [4] and
  2. Are released according to the MPAI-CUI Framework Licence (N202) [5], if selected by MPAI for inclusion in the MPAI-CUI standard.

The standard will be developed with the following guidelines:

  1. To satisfy the Functional Requirements (N200) [4]. In the future, MPAI may decide to extend MPAI-CUI to support other Use Cases.
  2. To be suitable for implementation as AI Modules (AIM) conforming to the MPAI AI Framework (MPAI-AIF) standard which is being based on the responses to the Call for Technologies (N100) [1] satisfying the MPAI-AIF Functional Requirements (N74) [1].

Rather than follow the approach of defining end-to-end systems, MPAI has decided to base its application standards on the AIM and AIF notions. The AIF functional requirements have been identified in [1], while the AIM requirements are Use Case-specific. It has done so because:

  1. AIMs allow the reduction of a large problem to a set of smaller problems.
  2. AIMs can be independently developed and made available to an open competitive market.
  3. An implementor can build a sophisticated and complex system with potentially limited know­ledge of all the tech­nologies required by the system.
  4. MPAI systems are inherently explainable.
  5. MPAI systems allow for competitive comparisons of functionally equivalent AIMs.

Respondents should be aware that:

  1. The currently addressed MPAI-CUI Use Case and the AIM internals will be non-normative.
  2. The input and output interfaces of the AIMs, whose requirements have been derived to support the Use Case, will be normative.

Therefore, the scope of this Call for Technologies is restricted to technologies required to implement the input and output interfaces of the AIMs identified in N200 [4].

However, MPAI invites comments on any technology or architectural component identified in N200, specifically,

  1. Additions or removals of input/output data to the identified AIMs with justification of the changes and identification of data formats required by the new input/output signals.
  2. Possible alternative partitioning of the AIMs implementing the Use Case providing:
    1. Arguments in support of the proposed partitioning.
    2. Detailed specifications of the input and output data of the proposed new AIMs.
  3. New fully described Use Cases.

All parties who believe they have relevant technologies satisfying all or most of the requirements of the Use Case described in N200 are invited to submit proposals for consid­eration by MPAI. MPAI membership is not a prerequisite for responding to this CfT. However, proponents should be aware that, if their proposal or part thereof is accepted for inclusion in the MPAI-CUI standard, they shall immediately join MPAI, or their accepted technologies will be discarded.

MPAI will select the most suitable technologies based on their technical merits for inclusion in MPAI-CUI. However, MPAI in not obligated, by virtue of this CfT, to select a particular tech­nology or to select any technology if those submitted are found inadequate.

Submissions are due on 2021/05/10T23:59 UTC and should be sent to the MPAI secretariat (secretariat@mpai.community). The secretariat will acknowledge receipt of the submissions via email. Submissions will be reviewed according to the schedule that the 8th MPAI General Assembly (MPAI-8) will define at its online meeting on 2021/05/12. Please contact the MPAI secretariat (secretariat@mpai.community),for details on how submitters who are not MPAI members can attend the said review.

2        How to submit a response

Those planning to respond to this Call for Technologies are:

  1. Advised that online events will be held on 2021/03/31 and 2021/04/07 to present the MPAI-CUI Call for Technologies and respond to questions. Logistic information on these events will be posted on the MPAI web site.
  2. Requested to communicate their intention to respond to this CfT with an initial version of the form of Annex A to the MPAI secretariat (secretariat@mpai.community) by 2021/04/13. A potential submitter making a communication using the said form is expected but not required to actually make a submission. A submission will be accepted even if the submitter did not communicate their intention to submit a response by the said date.
  3. Advised to visit regularly the MPAI web site where relevant information will be posted.

Responses to this MPAI-CUI CfT shall/may include the elements described in Table 1:

Table 1 – Mandatory and optional elements of a response

Item Status
Detailed documentation describing the proposed technologies mandatory
The final version of Annex A mandatory
The text of Annex B duly filled out with the table indicating which requirements identified in MPAI N200 [4] are satisfied. If all Functional Requirements are not satisfied, this should be explained. mandatory
Comments on the completeness and appropriateness of the Functional Requir­ements and any motivated suggestion to amend or extend them. optional
A preliminary demonstration, with a detailed document describing it. optional
Any other additional relevant information that may help evaluate the submission, such as additional use cases. optional
The text of Annex E. mandatory

Respondents are invited to take advantage of the check list of Annex C before submitting their response and filling out Annex A.

Respondents are requested to present their submission (mandatory) at a meeting by teleconference that the MPAI Secretariat will properly announce to submitters. If no presenter will attend the meeting, the proposal will be discarded.

Respondents are advised that, upon acceptance by MPAI of their submission in whole or in part for further evaluation, MPAI will require that:

  • A working implementation, including source code – to be used in the development of the MPAI-CUI Reference Software and later publication as a standard by MPAI – be made available before the technology is accepted for inclusion in the MPAI-CUI standard. Software may be written in a programming language that can be compiled or interpreted or in a hardware description language.
  • The working implementation be suitable for operation in the MPAI AI Framework (MPAI-AIF).
  • A non-MPAI member immediately join MPAI. If the non-MPAI member elects not to do so, their submission will be discarded. Direction on how to join MPAI can be found online.

Further information on MPAI can be obtained from the MPAI website.

3        Evaluation Criteria and Procedure

Proposals will be assessed using the following process:

  1. Evaluation panel is created from:
    1. All CUI-DC members attending.
    2. Non-MPAI members who are respondents.
    3. Non respondents/non MPAI member experts invited in a consulting capacity.
  2. No one from 1.1.-1.2. will be denied membership in the Evaluation panel.
  3. Respondents present their proposals.
  4. Evaluation Panel members ask questions.
  5. If required subjective and/or objective tests are carried out:
    1. Define required tests.
    2. Carry out the tests.
    3. Produce report.
  6. At least 2 reviewers will be appointed to review & report about specific points in a proposal if required.
  7. Evaluation panel members fill out Annex B for each proposal.
  8. Respondents respond to evaluations.
  9. Proposal evaluation report is produced.

4        Expected development timeline

Timeline of the CfT, deadlines and response evaluation:

Table 2 – Dates and deadlines

Step Date Meeting
Call for Technologies 2021/03/17 MPAI-6
CfT introduction conference call 1 2021/03/31T15:00 UTC
CfT introduction conference call 2 2021/04/07T15:00 UTC
Notification of intention to submit proposal 2021/04/13T23.59 UTC
Submission deadline 2021/05/10T23.59 UTC
Evaluation of responses will start 2021/05/12 MPAI-8

Evaluation to be carried out during 2-hour sessions according to the calendar agreed at MPAI-8.

5        References

  1. MPAI-AIF Use Cases & Functional Requirements, N74; https://mpai.community/standards/mpai-aif/
  2. MPAI-AIF Framework Licence, MPAI N101; https://mpai.community/standards/mpai-aif/#Licence
  3. MPAI-AIF Call for Technologies, N100; https://mpai.community/standards/mpai-aif/#Technologies
  4. MPAI-CUI Use Cases & Functional Requirements; MPAI N200; https://mpai.community/standards/mpai-cui/#UCFR
  5. MPAI-CUI Framework Licence, MPAI N201; https://mpai.community/standards/mpai-cui/#Licence
  6. MPAI-CUI Call for Technologies, MPAI N202; https://mpai.community/standards/mpai-cui/#Technologies

Annex A: Information Form

This information form is to be filled in by a Respondent to the MPAI-CUI CfT.

The purpose of this Annex is to collect data that facilitate the organisation of submission evalu­ation. Therefore, submitters are requested to only provide such data as Use Case(s) considered, types of technologies proposed, special requirements for (optional) demonstration and any other information that is functional to the evaluation of the submission.

  1. Title of the proposal
  2. Organisation: company name, position, e-mail of contact person
  3. What are the main functionalities of your proposal?
  4. Does your proposal provide or describe a formal specification and APIs?
  5. Will you provide a demonstration to show how your proposal meets the evaluation criteria?

Parties sending this Annex A are

  1. This Annex A should be only sent to the Secretariat
  2. Points 1., 3., 4., and 5. above will be made known to MPAI members. Point 2. will not be disclosed.
  3. The full submissions will be made available to MPAI members after the submission deadline of 2021/04/10.
  4. The Secretariat will not accept any confidential inforamtion at the time expression of interest is communicated to the Secretariat.

Annex B: Evaluation Sheet

NB: This evaluation sheet will be filled out by members of the Evaluation Team.

Proposal title:

Main Functionalities:

Response summary: (a few lines)

Comments on Relevance to the CfT (Requirements):

Comments on possible MPAI-CUI profiles[1]

Evaluation table:

Table 3Assessment of submission features

Note 1 The semantics of Submission features is provided by Table 4
Note 2 Evaluation elements indicate the elements used by the evaluator in assessing the submission
Note 3 Final Assessment indicates the ultimate assessment based on the Evaluation Elements

 

Submission features Evaluation elements Final Assessment
Completeness of description

Understandability

Extensibility

Use of Standard Technology

Efficiency

Test cases

Maturity of reference implementation

Relative complexity

Support of non-MPAI use cases

Content of the criteria table cells:

Evaluation facts should mention:

  • Not supported / partially supported / fully supported.
  • What supported these facts: submission/presentation/demo.
  • The summary of the facts themselves, e.g., very good in one way, but weak in another.

Final assessment should mention:

  • Possibilities to improve or add to the proposal, e.g., any missing or weak features.
  • How sure the evaluators are, i.e., evidence shown, very likely, very hard to tell, etc.
  • Global evaluation (Not Applicable/ –/ – / + / ++)

New Use Cases/Requirements Identified:

(please describe)

Evaluation summary:

  • Main strong points, qualitatively:
  •  Main weak points, qualitatively:
  • Overall evaluation: (0/1/2/3/4/5)

0: could not be evaluated

1: proposal is not relevant

2: proposal is relevant, but requires significant more work

3: proposal is relevant, but with a few changes

4: proposal has some very good points, so it is a good candidate for standard

5: proposal is superior in its category, very strongly recommended for inclusion in standard

Additional remarks: (points of importance not covered above.)

The submission features in Table 3 are explained in the following Table 4.

Table 4 – Explanation of submission features

Submission features Criteria
Completeness of description Evaluators should

1.     Compare the list of requirements (Annex C of the CfT) with the submission.

2.     Check if respondents have described in sufficient detail to what part of the requirements their proposal refers to.

NB1: Completeness of a proposal for a Use Case is a merit because reviewers can assess that the components are integrated.

NB2: Submissions will be judged for the merit of what is proposed. A submission on a single technology that is excellent may be considered instead of a submission that is complete but has a less performing technology.

Understandability Evaluators should identify items that are demonstrably unclear (incon­sistencies, sentences with dubious meaning etc.)
Extensibility Evaluators should check if respondent has proposed extensions to the Use Cases.

NB: Extensibility is the capability of the proposed solution to support use cases that are not supported by current requirements.

Use of standard technology Evaluators should check if new technologies are proposed while widely adopted technologies exist. If this is the case, the merit of the new tech­nology shall be proved.
Efficiency Evaluators should assess power consumption, computational speed, computational complexity.
Test cases Evaluators should report whether a proposal contains suggestions for testing the technologies proposed
Maturity of reference implementation Evaluators should assess the maturity of the proposal.

Note 1: Maturity is measured by its completeness, i.e., by disclosing all the necessary information and appropriate parts of the HW/SW implem­entation of the submission.

Note 2: If there are parts of the implementation that are not disclosed but demonstrated, they will be considered if and only if such com­ponents are replicable.

Relative complexity Evaluators should identify issues that would make it difficult to implement the proposal compared to the state of the art.
Support of non MPAI-CUI use cases Evaluators should check whether the technologies proposed can demonstrably be used in other significantly different use cases.

Annex C: Requirements check list

Please note the following acronyms

KB Knowledge Base
QF Query Format

Table 5 – List of technologies identified in MPAI-CUI N200 [4]

Note: The numbers in the first column refer to the section numbers of N200 [4].

Technologies Response
4.1.4.1 Governance data (raw) Y/N
4.1.4.2 Financial statement data (raw) Y/N
4.1.4.3 Risk assessment technical data (raw) Y/N
4.1.4.4 Governance Y/N
4.1.4.5 Financial statement Y/N
4.1.4.6 Risk assessment technical data Y/N
4.1.4.7 Financial features Y/N
4.1.4.8 Governance features Y/N
4.1.4.9 Severity Y/N
4.1.4.10 Decision Tree Y/N
4.1.4.11 Default probability Y/N
4.1.4.12 Adequacy of organisational model Y/N
4.1.4.13 Business continuity index Y/N

Annex D: Technologies that may require specific testing

Financial features
Governance features
Decision Tree

Additional technologies may be identified during the evaluation phase.

Annex E: Mandatory text in responses

A response to this MPAI-CUI CfT shall mandatorily include the following text

<Company/Member> submits this technical document in response to MPAI Call for Technologies for MPAI project MPAI-CUI (N202).

 <Company/Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N80), in particular <Company/Member> declares that  <Com­pany/Member> or its successors will make available the terms of the Licence related to its Essential Patents according to the Framework Licence of MPAI-CUI (N201), alone or jointly with other IPR holders after the approval of the MPAI-CUI Technical Specif­ication by the General Assembly and in no event after commercial implementations of the MPAI-CUI Technical Specification become available on the market.

In case the respondent is a non-MPAI member, the submission shall mandatorily include the following text

If (a part of) this submission is identified for inclusion in a specification, <Company>  understands that  <Company> will be requested to immediately join MPAI and that, if  <Company> elects not to join MPAI, this submission will be discarded.

Subsequent technical contribution shall mandatorily include this text

<Member> submits this document to MPAI-CUI Development Committee (CUI-DC) as a con­tribution to the development of the MPAI-CUI Technical Specification.

 <Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N80), in particular  <Company> declares that <Company> or its successors will make available the terms of the Licence related to its Essential Patents according to the Framework Licence of MPAI-CUI (N201), alone or jointly with other IPR holders after the approval of the MPAI-CUI Technical Specification by the General Assembly and in no event after commercial implementations of the MPAI-CUI Technical Specification become available on the market.

[1] Profile of a standard is a particular subset of the technologies that are used in a standard and, where applicable, the classes, subsets, options and parameters relevan for the subset


Use Cases and Functional RequirementsFramework LicenceCall for TechnologiesTemplate for responses to the Call for TechnologiesApplication Note

Template for responses to the MPAI-CUI Call for Technologies

Abstract

This document is provided as a help to those who intend to submit responses to the MPAI-CUI Call for Technologies. Text in res(as in this sentence) provides guidance to submitters and should not be included in a submission. Text in green shall be mandatorily included in a submission. If a submission does not include the green text, the submission will be rejected.

If the submission is in multiple files, each file shall include the green statement.

Text in white is the text suggested to respondents for use in a submission.

1        Introduction

This document is submitted by <organisation name> (if an MPAI Member) and/or by <organ­is­ation name>, a <company, university etc.> registered in … (if a non-MPAI member) in response to the MPAI-CUI Call for Technol­ogies issued by Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI) on 2021/03/17 as MPAI document N191.

In the opinion of the submitter, this document proposes technologies that satisfy the requirements of MPAI document MPAI-CUI Use Cases & Functional Requirements issued by MPAI on 2020/03/17 as MPAI document N151.

Possible additions

This document also contains comments on the requirements as requested by N200.

This document also contains proposed technologies that satisfy additional requirements as allowed by N189.

<Company and/or Member> explicitly agrees to the steps of the MPAI standards development process defined in Annex 1 to the MPAI Statutes (N80), in particular <Company and or Member> declares that  <Company and or Member> or its successors will make available the terms of the Licence related to its Essential Patents according to the MPAI-CUI Framework Licence (N201), alone or jointly with other IPR holders after the approval of the MPAI-CUI Technical Specif­ication by the MPAI General Assembly and in no event after commercial implem­entations of the MPAI-CAE Technical Specification become available on the market.

< Company and/or Member> acknowledges the following points:

  1. MPAI in not obligated, by virtue of this CfT, to select a particular technology or to select any technology if those submitted are found inadequate.
  2. <Company and/or Member> plans on having a representative to present this submission at a CAE-DC meeting communicated by MPAI Secretariat (mailto:secretariat@mpai.community). <Company and/or Member> acknowledges that, in no representative will attend the meeting and present the submission, this sub­mission will be discarded.
  3. <Company and/or Member> plans on making available a working implementation, including source code – for use in the development of the MPAI-CUI Reference Software and eventual public­ation by MPAI as a normative standard – before the technology submitted is accepted for the MPAI-CUI standard.
  4. The software submitted may be written in a programming language that can be compiled or interpreted or in a hardware description language, upon acceptance by MPAI for further eval­uation of their submission in whole or in part.
  5. <Company> shall immediately join MPAI upon acceptance by MPAI for further evaluation of this submission in whole or in part.
  6. If <Company> does not join MPAI, this submission shall be discarded.

2        Information about the submission

This information corresponds to Annex A on N191. It is included here for submitter’s convenience.

  1. Title of the proposal
  2. Organisation: company name, position, e-mail of contact person
  3. What are the main functionalities of your proposal?
  4. Does your proposal provide or describe a formal specification and APIs?
  5. Will you provide a demonstration to show how your proposal meets the evaluation criteria?

3        Comments on/extensions to requirements (if any)

 

4        Overview of Requirements supported by the submission

Please answer Y or N. Detail on the specific answers can be provided in the submission.

Technologies Response
4.1.4.1 Governance data (raw) Y/N
4.1.4.2 Financial statement data (raw) Y/N
4.1.4.3 Risk assessment technical data (raw) Y/N
4.1.4.4 Governance Y/N
4.1.4.5 Financial statement Y/N
4.1.4.6 Risk assessment technical data Y/N
4.1.4.7 Financial features Y/N
4.1.4.8 Governance features Y/N
4.1.4.9 Severity Y/N
4.1.4.10 Decision Tree Y/N
4.1.4.11 Default probability Y/N
4.1.4.12 Adequacy of organisational model Y/N
4.1.4.13 Business continuity index Y/N

5        New Proposed requirements (if any)

 

1. Y/N
2. Y/N
3. Y/N

 

 

6. Detailed description of submission

6.1       Proposal chapter #1

6.2       Proposal chapter #2

….

7        Conclusions


Use Cases and Functional RequirementsFramework LicenceCall for TechnologiesTemplate for responses to the Call for TechnologiesApplication Note

MPAI Application Note #7

Compression and Understanding of Industrial Data (MPAI-CUI)

Proponents: Guido Perboli (POLITO), Valeria Lazzaroli (Arisk), Mariangela Rosano (POLITO)

Description: Most economic organizations, e.g., companies, etc., produce large quantities of data, often because these are required by regulation. Users of these data maybe the company itself or Fintech and Insurtech services who need to access the flow of company data to assess and mon­itor financial and organizational performance, as well as the impact of vertical risks (e.g., cyber, seismic, etc.). For example, nowadays companies heavily rely on the security and dependability of their Information System for all the categories of workers, including the management of Industrial Control Systems. Adding into the risk analysis process cybersecurity-related parameters will help a more precise estimation of the actual risk exposure. Cybersecurity data will help a reassessment of financial parameters based on risk analysis data.

The sheer amount of data that need to be exchanged is an issue. Analysing those data by humans is typically on­erous and may miss vitally important information. Artificial intelligence (AI) may help reduce the amount of data with a controlled loss of information and extract the most relevant information from the data. AI is considered the most promising means to achieve the goal.

Unfortunately, the syntax and semantics of the flow of data is high dependent on who has produced the data. The format of the date is typically a text file with a structure not designed for indexing, search and ex­traction. Therefore, in order to be able to apply AI technologies to meaningfully reduce the data flow, it is necessary to standardize the formats of the components of the data flow and make the data “AI friendly”.

Comments:

Recent regulations are imposing a constant monitoring (ideally monthly). Thus, there is the pos­sibility to have similar blocks of data in temporally consecutive sequences of data.

The company generating the data flow may need to perform compression and understanding for its own needs (e.g., to identify core and non-core data). Subsequent entities may perform further data compres­sion and transformation.

In general, compressed data should allow for easy data search and extraction.

In a first phase MPAI-CUI is addressing primarily risk identification.

Examples

MPAI-CUI may be used in a variety of contexts, such as:

  1. To support the company’s board in deploying efficient strategies. A company can analyse its financial performance, identifying possible clues to the crisis or risk of bankruptcy years in advance. It may help the board of directors and decision-makers to make the proper decisions to avoid these situations, conduct what-if analysis, and devise efficient strategies.
  2. To assess the financial health of companies that apply for funds/financial help. A financial institution that receives a request for financial help from a troubled company, can access its financial and organizational data and make an AI-based assessment of that company, as well as a prediction of future performance. This aids the financial institution to take the right decision in funding or not that company, having a broad vision of its situation.

To assess the risk in different fields considering non-core data (e.g., non-financial data). Accurate and targeted sharing of core and non-core data that ranges from the financial and organizational information to other types of risks that affect the business continuity (e.g., environmental, seismic, infrastructure, and cyber). As an example, the cybersecurity preparedness status of a company allow better estimation of the average production parameters, like the expected number of days of production lost, which are affected by cyberattacks (e.g., days the industrial plants are stopped, days personnel cannot perform their work due to unavailability of the information system). Several parameters need to be considered, which are obtained by direct acquisition of data from the target companies that perform a cybersecurity risk analysis.

  1. To analyse the effects of disruptions on the national economy, e.g., performance evaluation by pre/post- pandemic analysis [1].

Requirements:

  1. The standards of the data in the data flow should be AI friendly. In other words, the different data required to predict a crisis/bankruptcy of a company should be gathered, carefully selected and eventually completed to be suitable for automatic analysis and then treated by an AI-based algorithm.
  2. The standard shall ensure efficiency of data structure, indexing and search, according to specific syntax and semantics.
  3. The standard shall all the extraction of main parameters with indication of their semantics.
  4. The standard shall support context-based compression (i.e., depending on the sequence of data).
  5. The standard shall support lossless compression.
  6. The standard shall support context-based filtering with different levels of details.

Object of standard:

Two main areas of standardization are identified:

  1. Inputs objects: a first set of data input related to:
    1. Financial data input
      1. Financial statements and fiscal yearly reports data (usually expressed in xls or xbrl formats). Their contents follow the accounting standards defined by the Organismo Italiano Contabilità (OIC) at the Italian level and the International Accounting Standards Board (IAS/IFRS) at the international level.
      2. Invoices. In Italy, the FatturaPA format is expressed in xml, but more in general invoices have to be compliant with the European standard EN 16931-1:2017.
  • Semantics of governance elements.
  1. Other economic data as company size uniformly recognized according to the size of employees or to the economic activities (e.g., classification elaborated by Eurostat and OECD data); imports and exports, etc…
  1. Vertical risks data input: in a preliminary phase, we will consider seismic and cyber, as vertical risks of primary interest. In the future, the object of the standard could be extended to cover other risks (e.g., related to infrastructures, sustainability). Generally, at the international level, the ISO/IEC 31000 standard defines the principles and guidelines related to the input data to consider for the risk assessment and management.
    1. Seismic risk. AI algorithm may help to define a socio-economic and technological model that will support companies and institution in defining reconstruction plan properly. In this direction, data input to assess seismic risk according to ASTM standards, will integrate:
    2. Technical data related to the existing/needed infrastructures (i.e., geolocation coordinates), architectural and urban planning data, as well as output data from the Building Information Modelling;
    3. Socio-demographic data, i.e., statistical data collected by certified sources (e.g., ISTAT in Italy, World Bank, International Financial Statistics, Worl Economic Outlook Databases, International Monetary Fund Statistics Data) about population figures, and their characteristics and distribution.
    4. Cyber risks. Considering cybersecurity-related parameters in the risk assessment will help to understand and estimate the impact of the actual risk exposure on the company performance, its financial health and business continuity.

As an example, an effective system to back up the sensitive data and testing periodically its effectiveness can be of help. Moreover, having well defined incident responses and a team prepared to deal with them, can help minimizing the effects of attacks and the time to recover. Therefore, an initial set of internationally recognised (ISO/IEC 27000 Information security management) inputs to consider are:

  1. Data related to assessment of organizational cyber management:
    1. organizational-level incident management (enumerate): no, simple plans available, detailed plan + IR Team, full integrated management (e.g., with a security operations center)
    2. backup management: no, user requested, automatic, automatic and tested
    3. vulnerability management (enumerate): no, assessement, management plans, with automatic tools
    4. enterprise patch management (enumerate): no, manual, automatic, testing
    5. specific cybersecurity and testing personnel (enumerate): no cybersecurity tasks, IT personnel with cybersecurity tasks, cybersecurity-trained roles
    6. cybersecurity procedure and mitigation testing (enumerate): no, occasional, planned, planned&frequent
    7. risk analysis: no, threats identified, assessment available, some mitigations implemented, full (mitigations implemented or justified, risks quantified)
  2. Data related to prevention of cyber-attacks. Being able to detect anomalies into an information system can allow preventing some attacks or discovering them before attackers, which can be estimated considering:
  3. monitoring: no, basic detection, integrated detection, organization-level, Security Information and Event Management (SIEM) software
  4. reaction: no, planned pre-configured responses, organized (some autom­atic), integrated tool-based & human supervised
  5. Data related to training. Studies report that the personnel that has followed spec­ific training on cybersecurity aspects that are relevant for their roles are more likely to avoid errors that may compromise the information systems of their companies (e.g., use better password, less likely to click on phishing emails). Training is even more important for personnel with cybersecurity-related responsibilities, hence:
  6. awareness/training cybersecurity personnel: no, occasional, frequent training
  7. awareness/training other categories: no, occasional, frequent, frequent and tailored per tasks.
  8. Data related to legal issues. An additional field where measuring the preparedness is the risk of losses due to legal issues (e.g., GDPR fines for
  9. availability of cybesecurity certification (enumerate): no, certifications relevant for the company business obtained
  10. compliance to regulations (enumerate): no, minimum, adequate
  11. Data for quantifying exposure. Whenever available, the following aggregated values can help to quantify the overall exposure to cybersecurity risks:
  12. overall risk exposure: monetization value from the risk assessment phase (number, directly obtained by the target company)
  13. mitigated risk exposure: monetization value after the risk mitigation phase (number, directly obtained by the target company)
  14. value of assets by security requirement: (Confidentiality-asset value/ Integrity-asset value / Availability-asset value)
  15. percentage of the value of assets-by-security-requirement on the overall value of the company assets: (Confidentiality-asset value/ Integrity-asset value / Availability-asset value).
  16. Output objects: represented by the outcome of the AI-based assessment in a format known by the user (format: Json)? This format is expressed in terms of a set of indexes that reflect the health of a company, the appropriateness of the governance and the impact of risks on economic-financial parameters. Some of these indexes are in response to legal requirements on business bankruptcy and crisis (e.g., DSCR), others are computed by means of a proprietary machine learning algorithm.

More in detail, the parameters in output are:

  • Risk index of the likelihood of company default in a time horizon of 36 months. It reflects the company performances based on the financial data.
  • Index of business continuity reflects the impacts of other risks on the previous measure.
  • Index of adequacy of the organizational model considers the impact of the governance on the performance of the company, highlighting possible issues in terms of conflict of interest or familiarity.
  • Debt service coverage ratio is a measurement of a firm’s available cash flow to pay current debt obligations

This is depicted in Figure 1 where the object of the standard is identified to be the intermediate format and the AI machine output.

Figure 1 – MPAI-CUI model

In some cases, internationally agreed input data formats exist. In several other cases a variety of formats exist. In these cases, meta formats to which existing formats can be converted should be defined.

The current framework has been made as general as possible taking into consideration the wide range of issues related to risk management. We are expecting the architecture to be enriched and extended according to inclusion of other risks and eventually the synergies with other MPAI applications.

Data confidentiality, privacy issues, etc. are for further consideration.

Benefits:  MPAI-CUI will bring benefits positively affecting:

  1. Technology providers need not develop full applications to put to good use their technol­ogies. They can concentrate on gradually introducing AI-based technologies that will allow a transition from traditionally approaches based on statistical methods, overcoming their limitations. This will enhance the accuracy of prediction and improve user experience.
  2. Service providers (e.g., Fintech and Insurtech companies, advisors, banks) can deliver accurate products and services supporting the decision-making process, with minimising time to market as the MPAI-CUI framework enables easy combination of internal and external-party compon­ents.
  3. End users as companies and local government can obtain an AI-decision support system to assess the financial health and deploy efficient strategies and action plans.
  4. Processing modules can be reused for different risk management applications.

Bottlenecks: The full potential of AI in MPAI-CUI would be limited by a market of AI-friendly data providers and by the adoption of a vast amount of information and data strictly dependent from the company and its context.

Social aspects:

A simplified access to the technologies under the MPAI-CUI standard will offer end users AI-based products promising for predictions and supporting the decision making in different contexts, reducing the effort of user in analyzing data and improving its experience which becomes more personal, but including a wide vision (e.g., thought benchmarking).

Moreover, the MPAI-CUI standard and the introduction of AI-based technologies will allow a transition from the present systems which are human readable, to machine readable technologies and services.

At the national level, governments can simulate the effects of public interventions and deploy proper strategies and plans in supporting the companies and economy.

Success criteria:

MPAI CUI becomes the bridge between traditional approaches in compliance with the actual regulation on prediction of business crisis and fully AI-based systems.

References

[1] Perboli G., Arabnezhad E., A Machine Learning-based DSS for Mid and Long-Term Company Crisis Prediction. CIRRELT-2020-29. July 2020.