KR20220004574A - System and method for Connection of ontology and financial DB using mapping table - Google Patents

Abstract

The present invention provides a system and method for interworking an ontology and a financial DB using a mapping table. The system comprises: an ontology DB that divides laws or regulations expressed in natural language into ontology elements through morphological analysis, then converts the same into ontology codes (OWL codes; hereafter referred to as ontology codes) and stores the same; a table creation module for generating a mapping request table by mapping an ontology code for each one or more items included in the table form information when the table form information is received from the client; and a report receiving module for transmitting the mapping request table generated through the table generating module to a financial company server, receiving report data corresponding to the mapping request table from the financial company server, and storing the received report data in a report DB. According to the present invention, natural language processing using deep learning such as morphological analysis of laws and regulations subject to concept verification is performed. The foundation has been laid for efficient resource use with the effect of reducing the time that can be processed in a shorter time than manual work. By using ontology, we have completed the distribution consistency and effective machine-executable regulation structure when laws and regulations are changed.

Description

System and method for Connection of Ontology and financial DB using mapping table {System and method for Connection of ontology and financial DB using mapping table}

The present invention relates to a system and method for interworking an ontology and a financial DB using a mapping table, and more particularly, after dividing laws or regulations expressed in natural language into ontology elements through morphological analysis, ontology code (OWL code; hereinafter) Ontology DB that converts and stores ontology code); a table creation module for generating a mapping request table by mapping ontology codes for each one or more items included in the table form information when the table form information is received from the client; and a report receiving module that transmits the mapping request table generated through the table generation module to a financial company server, receives report data corresponding to the mapping request table from the financial company server, and stores the received report data in a report DB; It relates to a system and method for interworking an ontology and a financial DB using the included mapping table.

The present invention relates to machine readable regulation.

As financial companies manually prepare 1,939 types of business reports (end of June, '18) on a regular (monthly/quarterly/half-year/yearly) basis in accordance with finance-related laws and regulations, the burden on the report preparation is heavy on financial companies, resulting in delayed submission and preparation. There is always the possibility of error

In various countries, there have been various discussions about MRR (Machine Readable Regulation; hereafter referred to as MRR) to improve it, whereas Korea is lukewarm compared to the size of the economy and the level of technological development.

Some of the lesser reasons include the problem of Korea's unique regulatory system and opposition from interest groups.

Focusing on the case of LegalTech, which can be said to be a higher level concept of RegTech, first, there is a prohibition on profits in the current Attorney Act, and in principle, anyone who is not a lawyer cannot participate in LegalTech according to this prohibition.

In addition, since legalTech combines capital and technology, corporations and public institutions must participate, but in principle, capital inflow is not possible in Korea.

If a profit is made as a result of the development of the invested capital, it is an environment in which capital cannot be administered because it would violate the Attorney's Law.

Second, lawyers are reluctant to accept LegalTech for fear of diminishing profits.

Although lawyers perform various tasks, most of them deal with litigation, and although simple litigation tasks are already feasible in LegalTech, there is a lack of awareness of LegalTech due to concerns about the decrease in the number of lawyers' work.

The purpose of the present invention, which has been devised to solve the problems as described above, is to perform natural language processing using deep learning such as morphological analysis of laws and regulations of the subject of concept verification, so that it can be processed within a shorter time than manual work. To provide a system and method for linking an ontology and financial DB using a mapping table that has established a basis for efficient resource use with a shortening effect, and completed an effective machine-executable regulation structure and consistency of distribution when laws and regulations are changed using the ontology. it is for

In addition, another object of the present invention is to increase the automation execution possibility of machine-executable regulation by using the web technology (Spring DATA JPA) technology of laws and regulations that have been converted into ontology (RDF, OWL), open API and hash value Prototype configuration of blockchain (HyperLedger Fabric) and use of financial cloud to prevent forgery using it is for

According to a feature of the present invention to achieve the above object, the interlocking system of ontology and financial DB using the mapping table of the present inventor divides laws or regulations expressed in natural language into ontology elements through morphological analysis. Ontology DB that converts and stores ontology code (OWL code; hereinafter, ontology code); a table creation module for generating a mapping request table by mapping ontology codes for each one or more items included in the table form information when the table form information is received from the client; and a report receiving module that transmits the mapping request table generated through the table generation module to a financial company server, receives report data corresponding to the mapping request table from the financial company server, and stores the received report data in a report DB; include

In addition, the financial company server, upon receiving the mapping request table, is characterized in that it matches the value stored in the financial DB according to the ontology code for each item.

In addition, the present inventor's system for interworking the ontology and financial DB using the mapping table is a report update module that receives from the financial DB corresponding to the selected report data and updates the report when any one of the report data stored in the report DB is selected through the client. ; characterized in that it further includes.

In addition, the report update module compares the hash value of the updated report data with the hash value previously stored in the block chain of the corresponding financial company and stores the final data in the report DB if they match.

According to another feature of the present invention for achieving the above object, the method of linking an ontology and a financial DB using the mapping table of the present inventor is (a) an ontology element through morphological analysis of laws or regulations expressed in natural language. After dividing into the ontology code (OWL code; hereafter referred to as the ontology code) and storing the converted into the ontology DB; (b) generating a mapping request table by mapping ontology codes for each one or more items included in the table form information when the table form information is received from the client; and (c) transmitting the mapping request table generated through the table creation module to a financial company server, receiving report data corresponding to the mapping request table from the financial company server, and storing the received report data in a report DB; includes

In addition, the financial company server, upon receiving the mapping request table, is characterized in that it matches the value stored in the financial DB according to the ontology code for each item.

In addition, the present inventor's method of linking an ontology and a financial DB using a mapping table is (d) when any one of the report data stored in the report DB is selected through a client, the report is updated by receiving from the financial DB corresponding to the selected report data. step; characterized in that it further comprises.

In addition, in step (d), the hash value of the updated report data is compared with the hash value previously stored in the blockchain of the financial company and, if they match, the final data is stored in the report DB.

According to the present invention as described above, natural language processing using deep learning such as morphological analysis of laws and regulations subject to concept verification is performed, and a time-saving effect that can be processed in a shorter time than manual work is a basis for efficient resource use It is possible to provide a system and method for linking ontology and financial DB using a mapping table that uses ontology to achieve consistency in distribution and an effective machine-executable regulation structure when laws and regulations change.

In addition, according to the present invention, by using the web technology (Spring DATA JPA) technology of laws and regulations that have been converted into ontology (RDF, OWL), the feasibility of automatic execution of machine-executable regulation is increased, and open API and hash values are utilized. Prototype configuration of blockchain (HyperLedger Fabric) and use of financial cloud to prevent forgery can provide a system and method for linking ontology and financial DB using an efficient mapping table through reduction of system configuration time and cost. have.

1 is an exemplary diagram illustrating the relationship with MDA according to an embodiment of the present invention from the viewpoint of CIM, PIM, and PSM;
2 is a flowchart of a data structure production process and a rule production process in DRR2
3 is a flowchart of a data structure manufacturing process and a rule manufacturing process for the MDA design process according to a preferred embodiment of the present invention;
Figure 4 is an exemplary view showing the self-developed CIM of MDA according to a preferred embodiment of the present invention
5 is an exemplary diagram showing an example of conversion of natural language regulatory sentences to PIM in PoC
6 is a block diagram showing the configuration of a machine readable regulation generation system according to an embodiment of the present invention;
7 is a flowchart illustrating a generation sequence of a method for generating a machine readable regulation according to an embodiment of the present invention;
8 is an exemplary diagram comparing public vs private DLT
9 is an exemplary diagram showing the entire analysis process of morpheme analysis and deep learning steps
10 is an exemplary diagram showing the entire analysis process of morpheme analysis and deep learning steps
11 is an exemplary diagram illustrating a morpheme analysis process process
12 is an exemplary view showing the result of morpheme analysis;
13 is an exemplary diagram showing deep learning analysis related to regulatory sentences
14 is an exemplary view showing the accuracy result of determining the performance with respect to the presence or absence of the ANN algorithm application rule
15 is an exemplary view showing the accuracy result of determining the performance with respect to the existence of the RNN algorithm application Rule
16 is an exemplary view showing the accuracy result of determining the performance with respect to the presence or absence of the LSTM algorithm application rule
17 is an exemplary view showing a morpheme analysis result and a processing result of performing deep learning
18 is an exemplary view showing a UI construction form showing whether ontology elements and regulatory sentences exist
19 is a block diagram showing the configuration of an ontology-based machine readable regulation visualization system according to an embodiment of the present invention;
20 is a flow chart showing a procedure of providing an ontology-based machine readable regulation visualization method according to an embodiment of the present invention;
19 is an exemplary diagram showing a flow for legal visualization
21 is an exemplary diagram schematically illustrating the content corresponding to the statute, which is a part of the overall structure of the statute ontology.
22 is an exemplary diagram showing the mapping of the contents of the ontology and the contents of the financial DB for the purpose
23 is a block diagram showing the configuration of an ontology and financial DB interworking system using a mapping table according to an embodiment of the present invention;
24 is a flowchart illustrating a method for interworking an ontology and a financial DB using a mapping table according to an embodiment of the present invention.
25 is an exemplary view showing two generated JPA Repository classes
26 is an exemplary diagram showing an example of an automatically generated Controller class that provides a report generation REST API
27 is an exemplary view showing a law search screen in the MRR visualization network
29 is a flowchart showing the overall work flow of the reporting system system concept verification process
30 is an exemplary diagram showing the configuration of each system according to the division of tasks for each system of the reporting system
31 is an exemplary view showing a report screen of the Financial Supervisory Service
32 is an exemplary view showing the screen configuration of the dashboard
33 is a structural diagram of a law change logic showing a work process of a reporting system when a law is changed.

Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings.

However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the art to which the present invention pertains It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout.

Hereinafter, the present invention will be described with reference to drawings for explaining a system and method for generating a machine readable regulation according to embodiments of the present invention.

The present invention relates to a system and method for converting laws or regulations expressed in natural language by wire or wirelessly from a client into a language that can be recognized through a program recorded on a recording medium.

First, to summarize the concept, the ontology described throughout the present invention means the original philosophical term 'ontology', and it is a concept borrowed from logic theory.

In the UK, etc., ontology languages such as OWL are used to express MRR.

Ontology is “an explicit specification of a conceptualization”, that is, it is one of the methods of modeling concepts existing in the world in a form that can be understood by machines, and it is a method of conceptual modeling.

According to the expressive power of the ontology language, the expression is richer in the order of XML, RDF, DAML (by DARPA), DAML+OIL, and OWL.

In particular, OWL is classified into OWL DL, OWL Lite, etc. depending on whether logic rules are expressed or not, and can have OWL Instance to manage only instance values separately.

Ontology language is usually composed as follows.

Entity: A generic term for all components that appear in a concept.

Class: Has the meaning of an object (eg laws, financial institutions, etc.)

Individual: Meaning of instance of Class (Example: Article 63 Paragraph 1, xx Bank, etc.)

Object Property: Meaning of relationship (eg, ‘supervision’ in supervision (financial supervisory institution, financial institution))

Data Property: Meaning of properties of objects (eg, name of financial institution, address, etc.)

There is no way to automatically create an ontology from texts such as financial laws.

However, in general, the following principles are followed:

Class: noun

Subclass and Superclass can exist

Individual: the actual value of a specific class as a noun or sentence

Object Property: There is a high possibility that three or more verb forms are applicable. In this case, the subject appearing in the sentence may be Class Domain, and the object may be Class Range.

Data Property: It is a noun type that characterizes the class, and it is highly likely to appear together with the class domain in the sentence.

Protιgι and OntoEdit are the most representative tools to support ontology (especially OWL, RDF) production, and since they generally provide Open API, they can be called from within the MRR system later.

VOWL and OWLVIZ are the most representative ontology visualization tools.

In order to analyze the regulatory text and visualize the ontology, the following process is required.

1, Morphological analysis is necessary to analyze natural language sentences.

Natural language processing technology is required to analyze regulatory sentences.

Natural language is a language used for the purpose of communication. It is a language that has been gradually developed historically, not artificially created or artificially manipulated.

Therefore, natural language is not a structured language that is easy to understand by computers (machines), which have been rapidly developed and developed in modern times.

Although computers were developed after natural language was used, they are also not structured to understand natural language well.

2. Unstructured data in sentence unit should be separated into word unit.

Since unstructured data is in a very complex form for a computer to process, it must be converted into structured data or a similar form.

The first step to transform unstructured data in natural language into structured data is a morphological analysis process.

Morphological analysis is the process of separating the entire text into morphemes, which are the smallest unit of meaning.

For example, when a sentence such as 'It is possible to verify that the signer is the payer after the electronic document is created' is input, the computer cannot treat the entire sentence as a unit.

To treat it as a unit, the unit must be used repeatedly in many cases, because the above sentence is rarely used again.

Therefore, just as numeric data determines one of the semantic units 0 to 9 for each unit, it is necessary to identify semantic units that are used repeatedly in natural language data.

3. It can be seen that each separate unit is used repeatedly in the document.

The nouns 'electronic document, signer, payer, person, confirmation, possible' as well as morphemes with formal meanings '-ga, -b, -i-, -ㅁ, -e' are used repeatedly in Korean sentences. is the form

They belong to the limited Korean vocabulary list in the subsequent machine learning stage, and they can be converted into numbers by attaching a unique identification number to each and used as structured data.

4. Replace unstructured data with number-type structured data.

The stemmed text data can be processed similarly to structured data.

When morpheme analysis is performed, it can be made into structured data expressed in numbers.

For example, column 1 is ‘child’, column 2 is ‘lunch’, column 3 is ‘dinner’, … and record whether the word is used in each position. For example, the position of 'lunch' becomes [ , 2], and the first sentence gives '1' to the corresponding position and '0' for the second sentence to record whether or not the word appears.

Since the text sentences classified in this way are frequency calculated in units of morphemes, they can be applied to the classification problem using the vocabulary of the sentences in the subsequent machine learning and deep learning processes.

There are about 10 open source stemming analyzers

Since the stemming analyzer takes at least several years to develop, the development institution has operated it only privately.

However, since 2010, when private interest in big data began to increase, versions distributed as open source began to appear.

In Koalanlp, which manages open source stemmers, 11 public stemmers are listed.

RHINO mentioned above is a public version, RHINO used in the present invention was performed with a private version (v3.7.3), and the public version and the private version have the same interface.

Machine learning is a technology that reproduces human learning ability on a computer.

Machine learning is an algorithm that automatically finds rules for the parts where humans need to establish all rules.

Machine learning is used in a wide range of fields, including search engines, spam detection, marketing prediction, DNA analysis, and speech and text pattern recognition.

The neural network algorithm used in the present invention has a structure similar to that of neurons in the brain, and its basic unit is as follows.

It is a structure in which several explanatory variables enter one neuron, that is, a node, and when it exceeds a certain level, it is output with weights.

As there are many neurons in the human brain, the basic algorithm of a neural network is to connect several nodes as above to find the optimal value.

A neural network consists of an input layer, a hidden layer, and an output layer.

The input node corresponds to the independent variable and the output node corresponds to the dependent variable, and the hidden node is arbitrarily configured.

When a specific memory is frequently recalled, a synapse is activated and the memory is well remembered. After completely connecting each node, the weight of the node is determined by figuring out which connection lines and nodes the learning data passes through.

A model with two or more hidden layers is called deep learning.

When a relational DB is used in a program, the existing JDBC or Mapper method (MyBatis, etc.) has high DB dependence, so productivity is low, maintenance is difficult, and compatibility problems occur according to various DBMS vendors.

A database is used for persistent data. In the architecture of a program, there is a persistence layer as a layer that gives persistence to data.

Instead of JDBC, which was widely used in the early days to implement the persistence layer for connection to the database, recently, the Persistence Framework is widely used without the complexity of JDBC programming or maintenance, and the high speed of development, easy maintenance, and high stability of operation. .

Persistence Framework can be divided into SQL Mapper method such as Mybatis and ORM (Object-Relational Mapping) method such as Hibernate.

The SQL Mapper method solves the problems of JDBC, but has the following problems compared to ORM.

The SQL Mapper method maps object fields directly using SQL. A query for CRUD (Create, Read, Update, Delete) is written using SQL. Even when developing with JAVA, an object-oriented language, dependency on DB increases, which lowers development productivity and makes maintenance difficult.

Also, since SQL is used directly, compatibility problems occur due to differences in SQL statements for each product when using other DBMS products such as Oracle, MySQL, or MS SQL Server.

The ORM (Object-Relational Mapping) method solves the problem of the SQL Mapper method by converting DB data into an object and enabling object-oriented development, and JPA (Java Persistence API), the Java standard of the ORM method, is provided.

The ORM method maps DB columns and object fields instead of writing SQL statements, and accesses the DB through this object.

If you use the ORM method, you do not create a query directly, but use the method with the created object to handle the DB, so object-oriented development increases productivity and maintainability.

Using the ORM method eliminates DB dependency when using a DB-independent language such as JPQL instead of SQL.

However, for complex queries that cannot be expressed in JPQL, Native SQL can be used.

Various development tools based on JPA, the JAVA standard for ORM, exist.

Java JPA changes the existing EJB ORM Entity Bean to JPA in the EJB 3.0 specification work in which several ORM experts participated, and collects standards for persistence management and ORM for JavaSE and JavaEE and provides them as interfaces.

JPA is an ORM standard interface technology, and Hibernate, OpenJPA, EclipseLink, TopLink Essentials, etc. are implemented as implementations.

As JPA based on Spring Framework, there is Spring Data JPA. Spring Framework is an open source application framework created by Rod Johnson for the purpose of facilitating enterprise application development by solving various problems of EJB.

There are various methods for JPA query methods, and the Query method method has great advantages in development and maintenance as it allows you to develop a program that can access the DB only by writing the method name.

An overview of the concept of MDA, its background, its basic structure, and its relevance to PoC is presented as follows.

MDA (Model-driven architecture) is an independent software automation technology proposed by OMG (Object Management Group).

Ideally, it is a technology to automatically generate code, and for this purpose, it is an approach to produce code according to the model according to the platform after designing it objectively (platform-independently) without designing the model dependently.

MDA appeared due to the complexity of CORBA, limitations of existing middleware, and changes in development paradigm.

The MDA basic structure has a structure in the order of CIM (Computation-independent model), PIM (Platform-independent model), PSM (Platform-specific model), and Code as follows.

The MDA relevance with this PoC can be described in terms of CIM, PIM, and PSM as shown in FIG. 1 .

In the case of DRR2, data structure and rule expression are described.

The data structure production process and rule production process in DRR2 are shown in FIG. 2 .

A summary of the DRR2 case is as follows.

SHACL has strength in knowledge expression in the closed world, and OWL has strength in knowledge expression in open world.

SHACL adopts the expression in the form of conclusion ← condition (if you want to ... you must ...), and in OWL, expression in the form of condition → conclusion (if ... becomes ...) is adopted.

However, since SHACL or OWL or an expression method focusing on descriptive logic is used, there is a limit to the expression of business rules that must be expressed with procedural knowledge.

Therefore, in this PoC, a separate rule expression method was developed.

The MDA design process in this PoC is shown in FIG. 3 .

In this PoC, the MRR element extractor based on the sentence type extraction meta rule and the LSTM based regulatory sentence determiner support the MDA process.

In other words, it is possible to reduce the time and effort to transfer natural language sentences to PIM through the semi-automatic generator, and to check consistency.

In this PoC, the self-developed CIM of MDA is shown in FIG.

Develop natural language regulatory sentences and RULE as components with self-developed PIM.

An example of conversion of natural language regulatory sentences to PIM in this PoC is shown in FIG. 5 .

The representation of each RULE will be developed as a component in PSM.

Create mapping table and perform ORM with self-developed PSM.

The mapping table creation and ORM process in this PoC is as follows.

Links machine-readable regulation information and financial DB information through a mapping table writer.

The financial DB was defined as a specific data dictionary (ie, PSM) of a financial company and would have been coded in SQL.

In PoC, standard financial DB was used and it was considered that it could be defined in advance, so it was solved with a mapping table and ORM.

Distributed Ledger Technology (DLT) model concept

DLT (Distributed Ledger Technology) is a basic technology that allows all participating organizations to share data from the same ledger in a network environment that can communicate with each other without a central management system.

It is possible to save the cost and time required for data transmission and reception and construction of the management system, and it is possible to check information updated in real time.

Data reliability can be secured with data encryption based on PKI (Public Key Infrastructure).

When distributed ledger is introduced

(Current introduction criteria) In order to understand what effect DLT can achieve, an introduction decision-making criterion is needed.

(Based on future introduction) It is expected to develop into a wide range of technologies except for cases that require extreme speed such as sharding, Raiden, and proof-of-work improvement (PoS) to solve the problem of DLT transaction speed.

(DLT type) You must choose between public, private, and consortium DLT types according to the governance (platform maintenance) of the DLT.

(DLT Platform) DLT is an immature technology that has not yet been standardized, and various platforms are competing, so it is necessary to select an appropriate SW.

(Security) Although DLT itself is a high-security technology, various security factors must be considered in order to implement a DLT system.

(Regulation) Controversial regulatory issues

Concerns about infringement of personal information (sharing personal and sensitive information)

Duty to destroy transaction records (transaction information cannot be deleted)

Ambiguity of legal responsibility in case of an accident

Conflict with the Electronic Financial Transactions Act based on a centralized computing environment

(Cost) It is necessary to compare the conversion cost and cost reduction effect of the existing system to DLT.

As open source, the introduction cost is low, but the cost increases during the operation stage.

* Open source maintenance cost, lack of developers, legacy linkage cost, system security cost separate from DLT's own security performance

** Comparison of storage capacity: Bitcoin block capacity (145 GB) vs securities DB capacity (2392 GB)

The cost aspect of DLT is to minimize the cost burden on users through new value generated in the DLT ecosystem rather than reducing system cost.

Cloud services provide various computing services through the Internet.

Compared to On-Premise, a certain part of management is performed by a cloud service provider or management tools are provided to reduce management points.

If necessary, specialized services that can satisfy specific conditions, such as big data and financial security requirements, are provided so that you can focus on realizing your work.

For startups with small capital and manpower, cloud-based devops construction is common.

DLT infrastructure configuration using the cloud is emerging as a way to quickly build multiple participating nodes.

Koscom Financial Cloud is a cloud dedicated to financial services and guarantees the highest level of security and safety.

By building a PoC system in Koscom Financial Cloud, it is possible to shorten the construction period of the PoC environment and verify the scalability required for future commercial services.

By using management services and management tools provided by Koscom Financial Cloud, management costs can be reduced compared to on-premises.

You can reduce unnecessary management and focus on work by using specialized services like API Gateway.

API (Application Programming Interface) refers to the method for sending and receiving data in any application program. It refers to an API that is open so that it can be called by web protocol (HTTP) so that it can be used externally.

It is used not only in map fields such as Naver Map, Kakao Map, and Google Map, but also in SNS, music, business, weather, shopping, etc., and is also used in public fields such as the Korea Financial Telecommunications and Clearings Institute's integrated account inquiry API and Koscom's open api platform.

The open API of the present invention can provide flexible RESTful API maintenance, backend service traffic control, secure API user authentication, and API usage monitoring dashboard by applying the API Gateway of the financial cloud.

MRR configuration in the present invention

6 is a block diagram showing the configuration of a machine readable regulation generation system according to an embodiment of the present invention.

Referring to FIG. 6 , the machine readable regulation generation system according to the present invention includes a conversion module 110 , an extraction module 120 , a determination module 130 , and a combination module 140 .

When a law or regulation expressed in natural language is input, the conversion module 110 converts the sentence into a morpheme similar to the structured data through morpheme analysis.

Here, in the morpheme analysis, when consecutive nouns are detected in one word, one or more nouns are attached and analyzed as one noun.

The extraction module 120 substitutes nouns and verbs into meta-language forms for the sentences converted into morphemes through the transformation module 110 and extracts ontology components.

Here, the extraction module 120 separately stores only sentences having the same sentence type as the previously analyzed sentence type condition through sentence type analysis of the sentence replaced with the meta-language form, and for sentences having the same sentence type as the sentence type condition, the sentence type The ontology components are extracted using previously recorded location information.

The determination module 130 determines whether or not a regulatory sentence exists through deep learning discrimination of the sentence converted into a morpheme through the transformation module 110 .

Here, in the deep learning determination, the existence of a regulatory sentence is determined through comparison with the determination model after making a determination model by accumulating and storing previously prepared learning data through a deep learning algorithm.

And, the existence of the regulatory sentence is determined by changing the character to an identifiable number through a deep learning algorithm and making the size of each sentence the same through a data padding process to create a decision model and replace it with a meta language. It is compared with the sentence to determine the existence of the regulatory sentence.

The combining module 140 combines the ontology component extraction result extracted through the extraction module 120 and the regulatory sentence existence determination result through the determination module 130 .

7 is a flowchart illustrating a generation sequence of a method for generating a machine readable regulation according to an embodiment of the present invention.

Referring to FIG. 7 , when laws or regulations expressed in natural language are input, the sentence is converted into a morpheme similar to the structured data through morpheme analysis (s110).

Here, in the morpheme analysis, when consecutive nouns are detected in one word, one or more nouns are attached and analyzed as one noun.

Next, with respect to the sentence converted into morphemes in step (s110), nouns and verbs are substituted into meta-language forms, and ontology components are extracted (s120).

Here, in the step (s120), only sentences having the same sentence type as the previously analyzed sentence type condition through sentence type analysis of the sentence substituted in the meta-language form are separately stored, and for sentences having the same sentence type as the sentence type condition, the sentence type dictionary The ontology components are extracted using the location information recorded in

Next, it is determined whether there is a regulatory sentence through deep learning for the sentence converted into a morpheme in the step (s110) (s130).

Here, in the deep learning determination, the existence of a regulatory sentence is determined through comparison with the determination model after making a determination model by accumulating and storing previously prepared learning data through a deep learning algorithm.

In addition, the existence of the regulatory sentence is determined by changing the character to an identifiable number through a deep learning algorithm and then making the size of each sentence the same through a data padding process to create a decision model and replace it with a meta language. It is compared with the sentence to determine the existence of the regulatory sentence.

Finally, the ontology component extraction result extracted in step (s120) is combined with the result of determining whether a regulatory sentence exists in step (s130).

The flow of the overall MRR design is to create an MRR corresponding to a PoC and conduct a regulation-based analysis based on it.

As the first mission, the laws expressed in natural language are MRR-coded so that machines (computers) can read them, and the subsequent procedures are as follows. In the present invention, MRR considers the OWL type ontology type in the same way as the DRR project.

First, to analyze regulatory sentences, regulatory sentences are extracted through natural language processing (morpheme analysis, sentence type analysis, regulatory sentence selection).

Second, MRR elements such as Class (Domain, Range), Object Property, Data Property, and Individuals are extracted.

Third, financial law experts refer to the extracted MRR elements to create and publish the MRR in the form of an OWL ontology.

For the second mission, regulation-based analysis (MER), it visualizes the contents of laws and creates a financial DB search program for report generation using ORM.

First, the statute is visualized based on the previously constructed MRR (using VOWL).

Second, the MRR report generation related information is mapped with the financial DB through the mapping table writer, and the result is created as a file.

Third, the API for consistency verification is developed, the report DB contents are reviewed for consistency, and the results are displayed.

Fourth, for some scenarios, change analysis is performed according to the occurrence of changes (additions, deletions, revisions) of laws and regulations.

MRR PoC’s Koscom Financial Cloud Structure

MRR PoC consists of a total of 11 VMs, reflecting the actual state of physically separated participating organizations.

Participating Organization 6, DB 1, Management 1, Web 1, WAS 1, GPU 1

Separate server (GPU) configuration for deep learning and visual OWL requiring high-spec CPU processing

The public IP that can be accessed from the outside is limited to the web server, focusing on security and management

Reduce unnecessary external communication by enabling internal communication between VMs

Distributed Ledger Technology (DLT) application plan of machine readable regulation PoC

Infrastructure uses Koscom Financial Cloud to improve management and time efficiency

DLT uses Hyperledger fabric for integrated management of ledgers, transactions, smart contracts, etc.

Allow business tasks to be processed with DLT through Koscom Fabric API Server

Report instruction and report generation Handling of business reports by the Financial Supervisory Service and financial institutions using smart contracts

Hyperledger Fabric

A DLT solution that provides high confidentiality, elasticity, flexibility and scalability

It has features such as member/identity management using MSP, privacy through channels, storage support, and chaincode support.

It is possible to share information transparently and reduce transaction costs in an enterprise environment.

Hyperledger Fabric is a private DLT that supports the features and functions shown in Figure 8 compared to public

Through the smart contract, the application program can be processed into the DLT ledger (KVS), so tasks such as data transmission and sharing between participating organizations and the creation of evidence data can be handled.

Fabric Server

DLT management and chaincode management owned by Koscom Restful API Server

In order for the application to manage the DLT and process the smart contract installed in the DLT, it is necessary to call the Fabric Server.

DLT design of MRR PoC

Node configuration

Consists of a total of 7 nodes (Financial Supervisory Service 1, financial institution 5, management 1)

Each node has one Peer* and Fabric Server.

Peer: A logical unit representing a node in the blockchain network, which holds DLT, state DB, and chain code, and is divided into Endorser, which plays a role of guaranteeing transactions, and Committer, which updates blockchain and state DB.

Channel configuration

It consists of one report instruction channel (6 Node Join) and 5 report management channels (the Financial Supervisory Service and each financial institution node).

In the report order channel, data can be shared by the Financial Supervisory Service and all financial institutions, but the report management channel maintains confidentiality because only two institutions belonging to the channel share data.

Channel: A logically separated blockchain network. Multiple independent channels in one network are possible. Each channel can have the same blockchain ledger to maintain confidentiality.

data structure

Smart contracts executed in DLT are divided into report instruction and report management.

Reporting instructions consist of items that the FSS can instruct financial institutions to generate reports.

Report management consists of some items and hash values of reports to be sent by financial institutions to the Financial Supervisory Service.

Workflow in Node

Based on the data structure, the Financial Supervisory Service uses the report instruction smart contract, and the financial institution uses the report generation smart contract to store and query data to perform business.

Prior to constructing the ontology as an MRR, the benchmarking target ontology model was reviewed.

With the advent of FIBO, various ontology models related to financial regulation are being developed. Representatively, FRO (Financial Regulation Ontology) and FIRO (Financial Industry Regulation Ontology) exist.

FRO: Open source ontology based on FIBO and Legal Knowledge Interchange Format (LKIF)

FIRO: Regulatory Ontology (by GRCTC) based on the knowledge of regulations and standards

The two ontologies have in common that they are based on FIBO and that they provide regulatory period services.

As a result of the review, the following ontology is found to be partially related to this PoC.

Analysis of PoC target laws

The PoC target consists of 4 laws and 4 reports, and the target laws have a hierarchical structure as shown in <Figure #>.

In general, delegation of authority takes place in the order of the constitution, statutes (law → enforcement ordinances → enforcement rules), administrative rules (instructions, ordinances, public notices), and self-governing laws (ordinances, rules).

Financial law also has a similar structure and has a hierarchical structure in which authority is delegated in the order of the Constitution, statutes, and rules.

Laws subject to PoC include Article 42 of the Electronic Financial Transactions Act, Article 24 of the Enforcement Decree of the Electronic Financial Transactions Act, Article 63 of the Electronic Financial Supervision Regulations, and Articles 10 and 11 of the Enforcement Rules of the Electronic Financial Supervision Regulations.

In the case of the Electronic Financial Transactions Act, analysis is performed by adding subordinate statutes due to the existence of a citation law.

In addition, as PoC target reports, the balance sheet, management guidance standard report, issuance and usage status of electronic direct payment means, and the status of issuance and use of electronic prepaid means are analyzed.

PoC customized stemming analyzer development design

It was developed using the morpheme analyzer developed by the present invention.

In the present invention, the RHINO morpheme analyzer developed in-house was used for morphological analysis.

RHINO is an abbreviation of Real Hangul INput Object and is a morpheme analyzer developed by the invention team at Kyunghee University.

By design, it has a structure that is optimized for analysis of Hangul, and in particular, the analysis function according to the context is excellent.

For example, two 'I' of 'I see a flying bird' are morphologically identical, but one is analyzed as 'day+is' and the other is 'I+is', and the part-of-speech is also 'verb+'. There is a difference between 'pronoun + pronoun' and 'pronoun + pronoun'.

In this case, RHINO analyzes the words of the same homonym well by examining the relationship between the front and back of the sentence.

High accuracy and speed. Under normal circumstances, the accuracy is maintained at 95-98%, and the speed analyzes 100,000-400,000 words per second.

RHINO has a public version and a private version, and the public version can be downloaded from GitHub or received with the Python pip command.

The dictionary of the morpheme analyzer was constructed to properly operate in the present invention.

Since the present invention team directly produced the morpheme analyzer, which is the basis of natural language processing, it is possible to add vocabulary and functions according to the purpose of the project, and to achieve perfect linkage with other processes.

In the present invention, examples of adding vocabulary include 'prepaid electronic payment means', 'credit specialized financial company', 'financial regulatory complaint portal', and the like.

Although the terminology is very large for each domain, it is not used unless it is the domain, so it is not registered in the basic dictionary and must be added separately.

In some cases, adding vocabulary is easy, but in some cases it is difficult depending on the structure of the morpheme analyzer. RHINO also has a total of 6 dictionaries, and specialized terms are appropriately entered according to the characteristics of the vocabulary.

An example of adding a function is a function of re-tagging consecutive nouns into a single noun. In the case of 'financial administration map', it is difficult to register as a single word because it is not a technical term.

In the ontology analysis of the present invention, which is a financial domain, it is often desirable to use a noun consecutive in one word as one component due to its nature.

Therefore, even if 'financial administration map' was analyzed as 'finance + administration + map' as a general morpheme analysis process, it is necessary to attach them again and regard them as one unit.

To this, a function was added to analyze consecutive nouns in one word by reattaching them as a single noun.

The function of the morpheme analyzer was added to suitably correspond to the present invention.

Functional linkage is related to how well you understand the program.

The method of morpheme analysis using RHINO is to retrieve only a specific morpheme from the ones showing all the most basic morphemes, to attach only a specific morpheme to a verb with endings and endings, to bring the entire morpheme while also getting part-of-speech information, and the word of the original text. There are five options, such as importing information as well.

These details of use were well adjusted so that the best results could be obtained in the subsequent sentence analysis and machine learning stages.

(Deep Learning-based) Regulatory Sentence Recognizer Design

The ontology components were extracted, and the suitability of the components was determined by deep learning.

The fundamental purpose of performing natural language processing in the present invention is to extract ontology components from each sentence and to determine whether the extracted components correspond to the contents of this domain.

Through this, it is intended to extract ontology components from financial regulatory sentences to be as automated as possible.

The entire analysis process of the morpheme analysis and deep learning steps is shown in FIG. 9 .

The entire process proceeds in the order of input of regulatory sentences, morphological analysis and substitution with meta-language, discrimination by deep learning, and combination of the two results.

In step ① described in FIG. 9, as mentioned above, when laws or regulations of the financial domain are input, the sentence is converted into a morpheme similar to the structured data through morpheme analysis.

Since the entire sentence cannot be a single analysis unit, morpheme analysis is to separate a sentence into a morpheme unit, which is a small unit that is repeatedly used.

Through this process, the subsequent mechanical process can proceed smoothly similarly to the process of processing structured data.

In step ②, for sentences converted into morphemes, the actual forms of nouns and verbs are removed and replaced with abstract meta-language forms such as NOUN and VERB.

In the sentence pattern analysis stage, it is not important what specifically used vocabulary is, but simply whether nouns and verbs are used.

Therefore, a word corresponding to a noun is replaced with NOUN, and a word corresponding to a verb is replaced with VERB.

Meta Rule-based sentence analysis is performed on the substituted sentence, that is, the meta language, and only sentences that have the same sentence type as the previously analyzed sentence type condition are stored separately.

For a sentence that has passed the sentence type condition, the ontology components are extracted using the location information recorded in the sentence type dictionary.

In step ③, deep learning discrimination is performed on the sentences converted into morphemes. The purpose of the discrimination is to predict whether each sentence has a regulatory sentence.

This process proceeds separately from the meta-rule transformation of step ② after the RHINO morpheme analysis process of step ① is completed.

The purpose is to make a decision model by training the pre-written learning data SET with a deep learning algorithm, and to use this to determine whether a new sentence is an ontology analysis target when a new sentence is entered.

As a result, if the sentence contains a regulatory sentence, it is classified as 1, otherwise it is classified as 0, so that the operator can quickly determine whether to consider the sentence as an analysis target and pay attention to it.

In step ④, the result of extracting ontology components through Meta Rule transformation in step ② is combined with the determination of the existence of regulatory sentences using deep learning in step ③.

Even if the ontology components are extracted through the steps ②, it is not actually a regulatory sentence, but it may be that the extraction process has been carried out.

At this stage, based on the deep learning judgment result, even if it is considered as the sentence type of the regulatory sentence in the sentence analysis process, it is reviewed once again.

As an example, FIG. 10 shows the above contents as a case where the electronic financial supervision regulations are entered.

When a regulatory sentence is entered, the RHINO morpheme analyzer separates it into the morpheme, which is the smallest unit of meaning.

The separated morpheme is checked whether it is a regulated sentence using a sentence pattern analyzer, and when it is confirmed, each ontology component class, property, range, domain, etc. is separated using the position information of the sentence pattern.

Meanwhile, on the machine learning side, a learning data SET is built with regulatory sentences, and a deep learning algorithm learns it to make a model that determines whether a regulatory sentence exists in each sentence.

As the deep learning algorithm used, RNN and LSTM, which are recurrent neural network algorithms that show good performance in text sentence judgment, can be considered.

Ontology element extractor design of regulatory sentences

The morpheme analysis process is divided into analysis target input, morphological analysis of the analysis target law, and recognition of classes and properties.

The above process is divided into a morpheme analysis process and an analysis process using deep learning, and only the morpheme analysis process process is shown in FIG. 11 .

The morphological analysis process goes through the following steps.

Analysis target input → morphological analysis of analysis target law → Class, property recognition

First, enter the regulatory sentences of the financial domain.

The input sentence used in the present invention is a sentence of the financial domain related to electronic finance.

The main content of the input text is the contents of the Electronic Financial Transactions Act, as the machine identifies the regulatory details related to electronic finance and transmits it to the relevant institution.

Then, morphological analysis is performed on the input regulatory sentence.

The inputted regulatory sentence to be analyzed is subjected to the following morphological analysis.

The input text is first separated into word units, which are spaces, and morphological analysis is performed for each word unit content.

Since a morpheme is always equal to or smaller than a word unit, it is first separated into word units to facilitate morpheme analysis.

Next, the linguistic unit is divided into the smallest unit, the morpheme unit, so that as many repetitive language units are found as possible.

The more repetitive units are found, the easier it is to determine whether two sentences are actually sentences with the same content.

Accordingly, in the first sentence above, the first word ‘Article 63’ is divided into ‘Article +63 + Article’, and the part-of-speech of each morpheme is also tagged. 'Z' is a prefix (XPN), '63' is a number (SN), and 'Jo' is a dependent noun (NNB).

A morpheme separated into a minimum semantic unit is a repeated unit, which can then be converted into structured data, and a tagged part-of-speech provides information to know whether a target element is present when converting into meta-language and analyzing sentence patterns.

Finally, the class and property of the ontology are recognized in the input sentence.

Each morpheme-separated sentence is converted into a meta-language through a preprocessing process so that sentence pattern analysis can be performed.

A meta-language refers to a record of nouns and verbs, which are major vocabulary constituting sentence patterns, in such a way that only the use of each noun and verb can be known without revealing the specific vocabulary used.

In this way, it is possible to compare and search variously expressed sentences using only a small number of sentence types.

The ultimate purpose of performing sentence pattern analysis is to extract the main vocabulary by using the location information of the main vocabulary recorded in the sentence pattern dictionary.

Here, the main vocabulary refers to the elements constituting the ontology, and refers to the Class and Property elements.

In order for the textual analysis to be performed, the expert in the relevant domain should build the textual dictionary in advance.

The sentence type information dictionary is a dictionary that presents each sentence type condition and specifies where the Class Domain, Class Range, Object Property, and Data Property are located in each condition.

Here, “position” refers to the number of nouns or verbs in the sentence condition that is a component of the corresponding ontology.

For example, if Class Domain is NOUN1, it means that the second noun appearing in the corresponding sentence is Class Domain, and the number of positions starts from 0.

12 is an exemplary view showing a morpheme analysis result.

Referring to FIG. 12 , the meaning of the first sentence condition is as follows.

The sentence condition starts with the ANY condition as ‘ANY NOUN1 is (is/is/is), ANY NOUN2 is VERB1’. The ANY condition says that no matter what expression comes, it must be PASS until the recorded content comes after it.

Therefore, this sentence-type condition can come before any word, and it starts with a noun (NOUN1), indicating that the conditional statement begins.

Next comes the investigation. As for the investigation, any of -i, -ga, -un, and - is treated the same.

Then again, there is an ANY rule, and any word is passed (PASS), and the second noun (NOUN2) must come again.

And it is saying that ‘-e’ or ‘-e’ must come, and finally the verb ‘hada’ must come.

On the right side, it specifies where the ontology elements belong to the sentence condition.

Class Domain is in the place of the first noun NOUN1.

Class Range is in the place of the second noun NOUN2.

Object Property is said to exist in VERB1.

There is no such thing as data property.

For example, in a specific sentence:

‘Article 1 (Purpose) This regulation is in the 「Electronic Financial Transaction Act」 (hereinafter referred to as the "Act") and the Enforcement Decree of the same Act (hereinafter referred to as the "Enforcement Decree")... When the sentence ' is input, first, the elements that are not helpful in the search for conditional sentences are deleted.

The elements to be deleted are prefixes, numbers, adjectives, and adverbs.

As a result, the sentence is ‘(purpose) regulations are in the 「Electronic Financial Transaction Act」 (hereinafter referred to as the "Act") and the Enforcement Decree of the same Act (hereinafter referred to as the "Enforcement Decree")... ' is converted to

The second stage of preprocessing is the morphological analysis process.

The morphological analysis step is to separate each word into the smallest unit of meaning.

At the same time, consecutive nouns within a word are converted into a single noun by re-tagging without separating them.

The third step in preprocessing is to remove the parentheses.

The content in parentheses supplements the content of the main text and is not directly connected to the context of the sentence.

Therefore, by deleting them, there is no hindrance to the search for conditional statements.

Delete parentheses can appear multiple times within a sentence, so it is performed repeatedly.

Next, the input statement is converted into a meta-language. Nouns are converted to NOUN and verbs are converted to VERB, and indexes are assigned according to the order in which they appear.

A sentence condition dictionary is searched for a sentence converted into a meta-language to find out whether it corresponds to the sentence type condition and, if so, what type of sentence condition it corresponds to.

As a result of meta-language transformation of the current input statement, ‘NOUN0 is NOUN1, NOUN2 is NOUN3, VERB0, NOUN4, NOUN5’.

If you search for a sentence type suitable for this meta-language, ‘NOUN1 is/is/is/is ANY NOUN2/is/NOUN3’ is found.

In the meta language of the input statement, there is a part corresponding to ANY of the conditional statement. This is not helpful in finding ontology components, so this part should be deleted.

For example, when a sentence such as 'Article 1, this regulation is in accordance with the matters entrusted to the Financial Services Commission by the 「Electronic Financial Transaction Act」 and the enforcement decree of the same Act, matters necessary for its enforcement, and other laws and regulations is entered, ' 'Transaction Act' to 'other' are part of ANY, so they will be deleted.

Extracts Class and Property from the last remaining sentence.

Since only the part corresponding to the rule is left in the sentence currently left, it is the task of finding the part designated as having Class and Property in the initial sentence type condition and bringing the corresponding vocabulary.

In the example below, the last remaining sentence is 'This regulation is in accordance with the law' and the sentence type is 'ANY NOUN1 is/is/is/is ANY NOUN1 to/to/to VERB0'.

Since those belonging to Class Domain are NOUN1, those belonging to Class Range are NOUN0, and those belonging to Object Property are VERB0, so the corresponding vocabulary ‘regulation’, ‘law’, and ‘follow’ are extracted respectively.

Deep learning analysis is performed to determine regulatory sentences.

The deep learning analysis process is performed separately from the morpheme analysis process, and the process is a process of constructing a learning data SET with the sentences to be analyzed as shown below, and creating a model that determines whether or not a regulatory sentence is a regulatory sentence with a deep learning algorithm.

13 is an exemplary diagram illustrating deep learning analysis related to regulatory sentences.

A learning data SET was constructed as a regulatory sentence in the financial domain.

As the regulatory sentences of the financial domain used in the present invention, the following statutes were used as the learning data SET.

Financial Regulation Operational Regulations

Electronic Financial Supervision Regulations

Electronic Financial Supervision Regulation Enforcement Rules

Enforcement Decree of the Electronic Financial Transactions Act

Electronic Financial Transactions Act

The above training data SET is 4,821 sentences, which is 75% of the total 6,429 cases, and the remaining 25% of the sentences are used to check the accuracy of the trained model.

The learning data SET was constructed with the morphologically analyzed data as follows.

Each sentence of the training data consists of three columns: id, body, and is_rule.

id is a unique identification number for each training data.

The main body is the content of the training data source text.

is_rule has an ontology component, so it is recorded by an expert whether or not it is an analysis target. If it is an analysis target, it is 1, otherwise it is 0.

Morphological analysis was performed on the sentences of the training data.

Which sentence was used to generate the learning data is identified by morphological analysis.

If one sentence is learned without modification, the pattern learning is not performed correctly because the entire sentence becomes one type.

It is necessary to analyze the vocabulary used in one sentence and to learn the pattern through whether the vocabulary used is similar.

Accordingly, morphological analysis was performed on the training data SET.

For morphological analysis, only real morphemes were taken.

Only morphemes that help sentence pattern analysis and sentence recognition were extracted.

All substantive morphemes were taken, and formal morphemes were selected only with high meaning and high frequency of use.

All symbols except those that are helpful for sentence classification were excluded.

The actual morphemes used are nouns (NNG), proper nouns (NNP), pronouns (NP), verbs (VV), adjectives (VA), roots (XR), adjectives (MM), adverbs (MAG), conjunctions (MAJ). , is an interjection (IC).

The formal morphemes used are indefinite determinant (VCN), connecting ending (EC), terminating ending (EF), noun-formal primal ending (ETN), adjective-formal primal ending (ETM), nominative postposition (JKS), complementary preposition (JKC), and tubular case. These are the pronoun (JKG), the adverbial proposition (JKB), the auxiliary (JX), the period, the question mark, and the exclamation point (SF).

Examples of morphological analysis results are as follows.

Separate each sentence into word units

Morphological analysis is performed on separated words

View the tagged part-of-speech type, and leave only the part-of-speech tag type presented above

Data preprocessing was performed for deep learning analysis.

Deep learning algorithms do not receive the string form directly, but must transform it into a number.

For example, if there are three words ‘finance, statute, provision’ in a sentence, each of them should be transformed into an identifiable number such as ‘101, 2133, 35’.

The allocation of numbers ensures that high-frequency vocabulary receives lower numbers based on their frequency of use in the entire text.

The process of transforming a string into a number is called data tokenizing.

The string transformed into a number goes through data padding again.

The data padding process makes every sentence the same size.

Small sentences are made equal to the specified size by adding ‘0’ in front.

Large sentences are removed from the front to make them the same size, and can also be removed from the back.

The LSTM algorithm was selected by comparing the performance of multiple deep learning algorithms.

The optimal algorithm was selected by applying multiple deep learning algorithms to the preprocessed data.

The algorithms used are three algorithms: ANN, RNN, and LSTM.

The result of determining the performance with respect to the presence or absence of the ANN algorithm application rule is shown in FIG. 14 .

As a result of performing 10 iterations, the 4th iteration showed the best performance.

It showed 96.6% accuracy in checking the accuracy of the test data.

The result of determining the performance with respect to the existence of the RNN algorithm application rule is shown in FIG. 15 .

As a result of performing 10 iterations, the 3rd iteration showed the best performance.

The accuracy of the test data was 96.7%.

The result of determining whether the LSTM algorithm application rule exists or not is shown in FIG. 16 .

As a result of performing 10 iterations, the 3rd iteration showed the best performance.

The accuracy of the test data was 97.1%.

As a result of comparing the performance of the above and three deep learning algorithms, they showed similarly good performance without much difference.

In the present invention, it was decided to use LSTM, because LSTM generally has better performance for classifying long sentences such as legal regulation sentences, and shows slightly better performance even in comparative experiments using actual data of the present invention.

Create an optimal LSTM model

For the selected LSTM algorithm, the optimal option, that is, the optimal hyperparameter, was found and a model with the best performance was created.

There are three types of hyperparameters: Embedding Dimension, which sets the number of words used for the embedding layer for similar vocabulary use, Hidden Layer, which sets the depth of the hidden layer, and Hidden Layer Node, which sets the number of nodes in each hidden layer. to be.

100 Embedding Dimension, 1 Hidden Layer, and 16 Hidden Layer Nodes were judged to be optimal, so the model was created accordingly.

The deep learning platform used to create the model is Tensorflow 1.16, Keras 2.2.4.

Keras is a wrapper package that makes Tensorflow easy to use.

The input layer consists of nodes of 2,330 word types used in the training data.

The embedding layer ensures that similar words have the same number, and it is determined that the sentences used in the training data are similar sentences even if they are not used in the actual data.

As one node of the output layer, it is decided by Y/N method by calculating with probability whether a Rule exists.

Combining morphological analysis results and deep learning performance results

By combining the results of morphological analysis and deep learning, experts who perform ontology work can work faster and more conveniently.

The processing result of the morpheme analysis is calculated as shown in FIG. 17 .

Creating an ontology element extractor

A program was developed that can automate the above process.

In particular, it supports the final author to work quickly by combining and presenting the result of extracting ontology components and the result of deep learning judgment.

From each sentence, the four main components of the ontology, Class Domain, Class Range, Object Property, and Data Property, are extracted, and the deep learning model creates a program that predicts the sentence that is presumed to have a Rule.

The purpose is to make the work easier by viewing the contents of the extractor when working with the ontology.

18 is an exemplary diagram illustrating a form of UI construction showing whether ontology elements and regulatory sentences exist.

The function of each component is as follows.

① A button that proceeds with the process of extracting Class and Property elements by applying the sentence condition rule to the original text

② A button that proceeds with the process of finding the sentence predicted to have a Rule through deep learning analysis

③ Button to output saved Class and Property elements to the screen

④ A window showing the current progress

⑤ Results window showing the contents of the original text

⑥ Result window showing vocabulary belonging to Class Domain

⑦ Results window showing vocabulary belonging to Class Range

⑧ Results window showing vocabulary belonging to Object Property

⑨ Result window showing vocabulary belonging to Data Property

⑩ Results window showing all nouns present in the sentence

⑪ Result window showing whether Rule exists. If it is expected that there will be a Rule, 1

OWL code generation design by domain experts

A domain expert creates an ontology code (owl) based on the extracted ontology elements and the regulatory sentence judgment results estimated by the machine.

For example, after classifying the ontology elements such as Clas Property Rule, a human intervention derives the machine code owl.

An ontology language (OWL code) is generated using an ontology solution (Protιgι).

Based on this, visualization, consistency check, report generation, and law analysis become possible.

Machine readable regulation visualization design

19 is a block diagram showing the configuration of an ontology-based machine readable regulation visualization system according to an embodiment of the present invention.

Referring to FIG. 19 , the ontology-based machine readable regulation visualization system according to the present invention includes an ontology DB 210 , a display module 220 , and a correction module 230 .

The ontology DB 210 divides laws or regulations expressed in natural language into ontology elements through morphological analysis, then converts them into ontology codes (OWL codes; hereinafter, ontology codes) and stores them.

When the output request information is received, the display module 220 converts the laws or regulations expressed in natural language stored in the ontology DB 210 according to the output request information from the upper laws or regulations according to the relationship between the elements of the ontology to the lower laws or regulations. up to the ontology tree structure.

Here, the output request information includes search information input through the client.

Then, when the search information is received, the display module 220 converts the search information into an ontology code, and detects and outputs one or more laws or regulations including the converted ontology code.

In addition, the ontology tree structure is connected and displayed in the order of sub-concepts of Articles, Sections, and Numbers from the higher-level laws or regulations.

The correction module 230, when the correction information is received after any one of laws or regulations expressed in natural language stored in the ontology DB 210 displayed on the display module 220 is selected, the replacement law information included in the correction information , and morphologically analyzes the detected replacement law information, divides it into ontology elements, and converts them into ontology codes and stores them.

20 is a flowchart illustrating a method of providing an ontology-based machine readable regulation visualization method according to an embodiment of the present invention.

Referring to FIG. 20, first, laws or regulations expressed in natural language are divided into ontology elements through morphological analysis, and then converted into ontology codes (OWL codes; hereinafter, ontology codes) and stored in the ontology DB 210 (s210). ).

Then, when the output request information is received, the laws or regulations expressed in natural language stored in the ontology DB 210 according to the output request information are converted into an ontology tree structure from a higher law or regulation to a lower law or regulation according to the relationship between ontology elements. is indicated as (s220).

Here, the output request information includes search information input through the client.

In the step (s220), when the search information is received, the search information is converted into an ontology code, and one or more laws or regulations including the converted ontology code are detected and output.

In addition, the ontology tree structure is connected and displayed in the order of sub-concepts of Articles, Sections, and Numbers from the higher-level laws or regulations.

Finally, when correction information is received after any one of laws or regulations expressed in natural language stored in the ontology DB 210 displayed in step (s220) is selected, replacement legislation information included in the correction information is detected and the detected replacement Law information is morphologically analyzed, divided into ontology elements, and converted into ontology codes and stored.

This is explained in detail as follows.

Based on the constructed ontology, the visualization is to intuitively grasp the contents of the law and to facilitate the analysis of the law.

21 shows a flow for legal visualization.

First, the ontology element visualization shows the ontology tree after being converted to VOWL through the ontology DB.

In addition, the visualization according to the change of the law reports the report of the existing law standard and the changed law standard.

22 is a schematic diagram of the content corresponding to the statute, which is a part of the overall structure of the statute ontology.

The main menu has a law ontology function, a law change analysis, and a law consistency function.

For example, it shows that a statute has Articles, Paragraphs, and Articles, and Articles, Paragraphs, and Articles have their respective sub-elements.

Different colors are applied to the words of the ontology, and when the figure part is clicked, the full text of the relevant law is displayed on the left side, thereby enhancing user convenience.

ORM design

In order to generate a report using ontology information, the ORM technology is required because the ontology contents and the financial DB contents must be linked.

In order to automate report generation, a JAVA jar program for report generation is created using ORM by inputting ontology-finance DB mapping information that stores the linkage information between ontology contents and financial DB contents.

23 is a block diagram showing the configuration of an ontology and financial DB interworking system using a mapping table according to an embodiment of the present invention.

Referring to FIG. 23 , the system for interworking between ontology and financial DB using the present inventor's mapping table includes an ontology DB 210 , a table generating module 310 , a report receiving module 320 and a report updating module 330 . .

The ontology DB 210 divides laws or regulations expressed in natural language into ontology elements through morpheme analysis, then converts them into ontology codes (OWL codes; hereinafter, ontology codes) and stores them.

When the table form information is received from the client, the table creation module 310 maps ontology codes for one or more items included in the table form information to generate a mapping request table.

The report receiving module 320 transmits the mapping request table generated through the table generating module 310 to the financial company server, receives report data corresponding to the mapping request table from the financial company server, and receives the report data It is saved in the report DB.

In addition, the financial company server, upon receiving the mapping request table, is characterized in that it matches the value stored in the financial DB according to the ontology code for each item.

When any one of the report data stored in the report DB is selected through the client, the report update module 330 receives the report data from the financial DB corresponding to the selected report data and updates the report.

In addition, the report update module 330 compares the hash value of the updated report data with the hash value previously stored in the block chain of the corresponding financial company and stores the final data in the report DB if they match.

24 is a flowchart illustrating a method for interworking an ontology and a financial DB using a mapping table according to an embodiment of the present invention.

Referring to FIG. 24, first, laws or regulations expressed in natural language are divided into ontology elements through morphological analysis, and then converted into ontology codes (OWL codes; hereinafter, ontology codes) and stored in the ontology DB 210 (s310). ).

Then, when the table form information is received from the client, an ontology code is mapped for each one or more items included in the table form information to generate a mapping request table (s320).

Then, the mapping request table generated through the table creation module is transmitted to the financial company server, the report data corresponding to the mapping request table is received from the financial company server, and the received report data is stored in the report DB (s330) .

Here, the financial company server, upon receiving the mapping request table, matches the value stored in the financial DB according to the ontology code for each item.

Then, when any one of the report data stored in the report DB is selected through the client, the report is updated by receiving from the financial DB corresponding to the selected report data (s340).

Here, in step (s340), the hash value of the updated report data is compared with the hash value previously stored in the block chain of the corresponding financial company, and if they match, the final data is stored in the report DB.

This is explained in detail as follows.

25 is an exemplary diagram showing the mapping of two generated JPA Repository classes, the ontology contents and the financial DB contents, in association with each other.

The reason for adopting ORM is that it is judged as the most suitable method for automating the task of receiving mapping table information and retrieving data required for report generation from the financial institution DB.

By utilizing ORM, there is no need for a separate manual operation to search the DB in the current PoC target report.

Among the methods (Raw JPA, QueryDSL, Spring Data JPA) compliant with Java ORM standard JPA, select the Spring Data JPA method that provides the Query Method to automatically create a class for financial DB access.

With the Query Method, you can easily create a query for DB access with a combination of column name and conditional keyword.

Report fields, which are difficult to map to columns of financial DB, are processed with @Query annotation to generate codes.

Based on the JPA Entity and Repository classes, to create a report generation jar file with a RESTful interface, a Service class and a Controller class are also automatically created based on spring boot.

To generate a report, a service class is created according to the format by receiving the report information CSV containing the report format information as input.

It was developed by minimizing data input information containing DB table schema information.

In order to display the DB table as a JPA Entity, which is a JAVA object, schema information of the DB table is required.

Use only four pieces of information, such as to minimize the information used.

The scalability is increased by determining the data input information by generalizing the report format type for the report information necessary for creating a report.

Two types of report format are supported: basic (BASIC) and double-layered (TWO_LAYERS).

The basic type is an array of (name, values) pairs in a single layer without a detailed structure, and the double layer type is a structure in which the parent is an array of (name, items) pairs, and each item has an array of (name, values) to be.

As an additional detailed type in the report format, if it is output by group, specify [GROUP], otherwise, specify BASE (current), PREVIOUS (early), and DIFFERENCE (increase or decrease) according to the required details.

For example, specify [BASE;PREVIOUS] if only current and previous years are required, and [BASE;PREVIOUS;DIFFERENCE] if increase or decrease is required. In this case, BASE can be omitted.

Mapping information between report fields and columns in DB tables is developed flexibly to accommodate various calculation methods of report items.

Report item JSON notation indicates the item name when the report item is expressed in JSON format. In the case of the TWO_LAYERS report format, the names of the upper and lower layers are separated by “/” and displayed continuously.

When the report detail attribute is GROUP, since item values must be displayed for each group, an item whose report item type is GROUPS must exist in order to output the group name, and the values of the group names are given as user input text.

Other items in the report have types such as NUMBER_BY_GROUPS or STRING_BY_GROUPS.

The user input text of the GROUPS item is given in the order in which pairs of “group name: group code” are displayed, for example, it has a value of “registered: 01; anonymous: 02”.

The user text input is used to input a constant value like the GROUPS item or a conditional expression used when a value needs to be calculated through a query.

Create a JPA Entity class for each DB table using DB schema information.

When creating the Entity class, the class name is appended with EntityFor in front of the Camel notation of the table name. For example, if the table name is dpay_appr_list_tbl, it becomes EntityForDpayApprListTbl.

In front of the Entity class declaration, use the @Entity annotation to indicate that it is an Entity, and use the @Table annotation to write the corresponding DB table name. Since Hibernate automatically converts to snake notation using Camel notation ‘_’, write the DB table name in Camel notation like dpayApprListTbl.

The fields of the entity represent the columns of the DB table. Instead of listing all the columns, the Entity is displayed concisely by listing only the columns used for report writing and the primary key that must appear in the entity.

The entry field name is the Camel notation of the DB table column name.

If the primary key consists of a single column, an @Id annotation is added in front of the field to indicate that it is the primary key. make extra

Create a JPA Repository class for each JPA Entity using report-DB mapping information.

When the report field and the column of the DB table correspond one-to-one, the method name that meets the query condition is created according to the method naming convention of Spring Data JPA Repository.

In the four types of Poc reports, the query conditions that occur when a report field and a column of a DB table correspond one-to-one are date conditions, and can be classified into two types.

One is a POINT query to search for a specified date, and the other is a RANGE query to search for a specified period. In the former case, the method name is created as findBy + date condition_column + Equals, and in the latter case, findBy + date condition_column + Between.

The JPA Repository method created above returns all columns of tuples that match the query condition.

Therefore, if the query condition is the same, one method is created instead of repeatedly created, and the return type of the method is the corresponding Entity class name.

If the report field and the column of the DB table do not correspond one-to-one, you must use a query to obtain the required value.

To do this, write a query for each report field and create a method to execute the query.

The method name is named find + “report field name” to make the meaning easier to understand.

Depending on the report field type, the return type of the method is given as Long for NUMBER, String for STRING, and List<Object[]> for NUMBER_BY_GROUPS.

Here, Object[] represents one tuple, and the elements of the array are mapped to one tuple element, and one tuple is returned for each Group, so it is received as a List.

Writing a query is divided into the case of obtaining an aggregate value through grouping and the case of obtaining an aggregate value without grouping. If there is grouping, it is composed of “SELECT grouping column, aggregate function (aggregate column) FROM DB table WHERE conditional statement GROUP BY grouping column”.

In the case of the date condition in the conditional statement, the specified date condition is “date condition_column = ?1” and the specified period condition is “date condition_column BETWEEN ?1 AND ?2”. Here, ?1 and ?2 indicate a place to receive parameters.

The user input condition given in the report-DB mapping information is connected to the date condition with AND to create a final conditional statement.

The format parameters of the Repository method are created as “()” if there is no date condition according to the date condition, “(String baseMonth)” for the specified date condition, and “(String startDate, String endDate)” for the specified period condition.

22 shows the automatically generated BalanceTblRepository and DpayApprListTblRepository, respectively. The former has only a method by the query method, and the latter includes a query method using the @Query annotation.

For one report, Spring Service class is created using report information and report-DB mapping information.

The name of the Service class is named by appending Service after the name of the REST API URL to use the service.

For each field of the report, the method of the corresponding repository used to obtain the field value is called, and the return value is processed and the value is stored in the corresponding field of the Java object representing the report.

Declare only one repository object even if it is used multiple times for the used Repositories, and add @Autowired annotation for automatic injection of Spring's dependent objects.

When several report fields correspond one-to-one with columns of one DB table, the corresponding fields are extracted from the return entity object after calling the same method of the same repository.

In this case, the number of query executions is reduced by calling the method only once for efficient execution.

When calling a method, it is called by passing the date condition value entered by the user according to the type of query condition. If there is no date condition, it is called “()”, if it is a specified date condition, it is called “(baseMonth)”, if it is a specified period, it is called “(startDate, endDate)”.

If the report type is output by group, the list of (group name, group code) is first maintained in LinkedHashMap when the service class is called and processed for the field whose type is GROUPS among the report fields.

LinkedHashMap can quickly find the group code from the group name while keeping the groups in order.

When the report type is output by group, fields other than the GROUPS field are STRING_BY_GROUP or NUMBER_BY_GROUP type fields, and values are extracted for each group.

STRING_BY_GROUP extracts a string for each group from the user input text in the report-DB mapping information.

Since the STRING type is a non-aggregated value, it cannot be expressed in an SQL statement using the GROUP BY statement.

NUMBER_BY_GROUP outputs values in the same order as the group names listed in the GROUPS field of the report.

For this, the list of LinkedHashMap structure created when processing the GROUPS field is used.

In the report type, according to the detailed attributes of the report format type, not only the current year, but also the posting and change details are entered in the report. For example, if there are no detailed properties, by default, only the details pertaining to the current period are output.

When calculating field values for postings, the date condition uses the value of the month or the last day of the month, depending on whether the report cycle is quarterly, semi-annual, or annual.

By using the atEndOfMonth() method of Java's YearMonth class, the problem caused by the difference in the last day of the month is solved.

Create a Controller class that receives the REST API and returns the corresponding report in JSON format.

The Controller class plays a role of connecting with the service class that generates the report according to the called url.

By using spring framework, concise code is generated by automatic injection.

Next, Figure 26 shows the automatically generated Controller class.

There is only one Controller class in the whole program.

Reporting system system area

The reporting system is divided into three functionally

Report UI: A web-based screen in which the Financial Supervisory Service officer instructs, reads, and monitors the creation of a report, and the financial institution manager creates, reads, and submits the report.

Report open API: API that performs the function of securely transmitting and receiving report data between the physically separated financial company system and the Financial Supervisory Service system

Financial company API: API that resides in the financial company system, recognizes the report generation instruction of the Financial Supervisory Service, extracts report data from the financial DB, and delivers the function to the Financial Supervisory Service system

MRR proof-of-concept implementation

Current laws and regulations and report system

MRR visualization

A tree structure is expressed for the PoC target laws.

When the created OWL file is created, the entire legal system can be seen at a glance.

They appear in the order of laws - Articles - Paragraphs - Subparagraphs.

You can visualize the details of the MRR components and understand their relationships.

Classes, properties, individual, etc. are expressed.

Visually express how the relationship between each component is.

You can search for statutes included in the MRR written in OWL and view the elements of the statute.

Since it is difficult to see the entire structure of complex laws at a glance, a law search function is provided so that you can search for a desired law and view the details of the law.

In addition, if you enter a search term in the lower right corner, the relevant laws, reports, or MRR elements are searched and, if necessary, can be enlarged.

Search for the law you want and click the button to expand to the relevant law.

If you visualize the entire statute after POC, the structure is larger and more complex, so the search function is essential.

If UI development continues in MRR visualization, it can be configured to increase visibility and make it easier for users to understand.

27 is an exemplary view showing a law search screen in the MRR visualization network.

The rules expressed in OWL codes and PIMs related to the selected MRR elements such as laws and regulations are expressed.

Through the OWL code, which is the core of MRR, you can check the OWL code that contains all the information used for MRR.

When you click Details, you can check the name, domain, scope, and details of the law for the selected law.

Clicking a comment in the statute details will take you to the consistency simulation page.

MRR Visualization Help

We provide a help page to help you understand MRR and the whole process.

It includes a description of the ontology that is the core of MRR.

Provides user guides and help to solve any questions you may have about using the system.

Analyze regulatory laws and judge the consistency of specific report contents

In the MRR visualization page, you can test the consistency of each financial institution's report for the found statute.

It is possible to judge the consistency of each report based on the current law that has not been changed.

Various variables included in the relevant laws (total assets, total liabilities, outstanding balance, number of franchisees, etc.) should be updated and stored in the database. This assumes that there is data from the FSS database because reports are received from financial institutions according to the submission deadline.

If the structure of the statute becomes more complex, a more advanced rule set and decision logic should be applied, and it may not be possible for some laws.

In case of further development, it is possible to simulate and assume how the financial status of financial institutions will change in the future based on the current laws.

Converting the original text of the statute into a machine executable

This is related to the formula, so it is not difficult for the user to understand, and the change simulation is easy.

Current legal standards: Comparing with the report conformity judgment, it is possible to simulate the degree to which financial institutions conform when the standard numerical values and values in the law are changed.

If the structure of the statute becomes more complex, a more advanced rule set and decision logic should be applied, and it may not be possible for some laws.

Analysis of statutory changes

In the law change analysis menu, starting from the current MRR screen, search for the law you want to change and find it.

Click the bar at the bottom to bring up the text of the statute to be changed.

If the amount of legislation increases in the future, a search/select function is required similar to the MRR visualization.

Select the part you want to change.

It is possible to add, delete, and amend laws and regulations.

When modifying laws, the user can apply an editor for convenience.

change the laws

If you click the edit button after deleting/adding the items to be changed in the imported laws, the laws to be changed are saved.

It reflects the change in the MRR factor due to the change legislation.

When the law analysis start button is pressed, the AI and morpheme analysis program analyzes the stored law.

The analysis program is requested to run through the API.

In the present invention, it is necessary to separately configure the manager page for when new learning is performed and the model is to be changed in terms of maintenance management.

Click Start to run the analysis.

The present invention may take some time because the amount of laws and regulations is expanded.

A separate UI is needed to display the progress during the waiting time.

After the text to be changed is saved, AI performs natural language processing on the saved text.

Sentences for regulations are extracted through natural language processing.

Determine the MRR components from the extracted sentences.

The MRR component is displayed on the screen.

Referring to the generated and displayed MRR elements, the expert creates OWL using protege.

By internalizing the protege into the MRR system, it is possible to automate even the creation of OWL.

Therefore, if the user revises the text of the law, full automation is possible until the changed MRR result is received.

When the OWL creation is completed, the current MRR visualization and the MRR visualization screen to be changed are displayed.

If there is a large structural change, the user can easily see it, but if not, it highlights the location of the change.

Notify financial institutions of changes in laws and regulations.

In the present invention, the known process can be separated separately.

Mapping Table Builder

A mapping table is created to analyze the current legislation and create OWL, and to map it to the financial institution DB.

Once the mapping table is configured, there is no need to repeat it additionally. However, if a new law that did not exist before is added, a new table must be mapped.

The mapped table is delivered to the financial institution along with the generated jar.

Represents a list to be mapped to properties extracted from OWL.

To connect financial institution DB, each property is mapped.

If you click the Create CSV button, a csv file is created and saved to the server.

ORM

When table_info.csv and MRR-Finance DB mapping information are saved, ORM automatically creates a program that retrieves related data from the financial DB.

If you click the java generation file button, the mapped table and jar are created through the java program.

Deploy the mapped table and jar through java program.

Reporting system area

Reporting Scheme System Concept Verification Process

29 is a flowchart illustrating the overall workflow of the reporting system concept verification process.

At the time of periodic report submission (annual/half-annual/quarterly), automatic arrangement by scheduling or the person in charge of the Financial Supervisory Service instructs the report to be generated irregularly on the report web screen.

The report generation instruction stores the instruction instruction in the blockchain of the entire financial company through the Financial Supervisory Service blockchain.

The person in charge of the financial company checks the regular/irregular report generation instruction from the Financial Supervisory Service through the report web screen and generates the report.

When performing report generation, the generation command is stored in the blockchain of the financial company.

The financial institution API program in the financial institution system automatically recognizes the creation command stored in the block chain and performs the creation. The process of generating report data is:

It determines whether the report data extraction program created in the MRR system has been changed and downloads it to the financial institution server.

Run the downloaded program

Extract the report data instructed by the Financial Supervisory Service from the financial institution DB

The hash value of the extracted report data is stored in the blockchain of the financial institution.

Validate the consistency of the extracted report data and save the final data including the result in the report DB

The person in charge of the financial company reads the report generated for data inspection. At this time, the report screen is exposed if they match through forgery verification that searches the hash value stored in the block chain and compares the hash value of the report data stored in the report DB

The person in charge of the financial company checks the report data and submits it to the Financial Supervisory Service

The person in charge of the Financial Supervisory Service reads the report submitted by the financial company. Also, at this time, the hash value stored in the block chain is searched, the hash value of the report data stored in the report DB is compared, and if they match through forgery verification, the report screen is exposed.

Classification of tasks by reporting system system

30 is an exemplary diagram illustrating the configuration of each system according to the division of tasks for each reporting system system.

Financial Supervisory Service System

Report UI: A web screen used by the Financial Supervisory Service and financial company managers to process report-related tasks

Report Open API: API for determining whether the program for extracting report data received from the MRR system has been changed, downloading the program to the financial institution system, receiving the generated report data from the financial institution system, verifying consistency, and storing the report DB

Blockchain network: Stores the report generation instruction information of the Financial Supervisory Service and shares it with all financial companies

financial institution system

Financial company API: API for downloading and executing a program for extracting report data from the MRR system, extracting report data from the financial company DB, and sending it to the Financial Supervisory Service system

API Gateway

A system that acts as a relay when the financial institution API calls the Financial Supervisory Service's report Open API

Secure support to hide the direct address when calling the report Open API

Even if the report Open API call address is changed at the time of operation, the financial institution API does not change, only the mapping address in API Gateway needs to be changed, so changes can be reflected in real time

Supports secure and secure data communication between the physically separated Financial Supervisory Service system and the financial institution system

Reporting System Financial Supervisory Service Business Process

Report generation instruction: A person in charge of the Financial Supervisory Service instructs a financial institution to generate a report

View Report: View reports submitted by financial institutions to review report data

Verification of report data forgery: Verification of forgery by comparing the report data hash value stored in the block chain with the report data hash value stored in the report DB when viewing the report

Verification of report consistency: At the time of saving report data generated by financial institutions, it is determined whether the data violates laws and regulations, and the result of verification of consistency is saved together with the report data.

Law change notification function: When a law change occurs, it is notified from the MRR, and a notification is displayed so that it can be recognized on the report screen and detailed information is displayed on the screen

Reporting system Financial company business process

Report data extraction program processing: Automatically recognizes the block chain saved report generation command to determine whether the report data extraction program has been changed

Report creation/reading/submission: A person in charge of a financial company creates a report instructed by the Financial Supervisory Service, reads the generated report, and submits it

Report data hash value storage: The report data extracted from the financial institution DB is stored in the block chain as an encrypted value using the SHA256 hash algorithm and used to verify forgery and falsification when viewing the report.

Financial Supervisory Service report screen

31 is an exemplary view showing a report screen of the Financial Supervisory Service, and FIG. 32 is an exemplary view showing a screen configuration of a dashboard.

The status of submission of reports ordered by the Financial Supervisory Service is expressed in a bar graph with respect to the number of submissions/non-submissions by region.

It is possible to compare and review the submission/non-submission ratio by region through a more detailed search according to the base year and cycle.

By selecting the bar graph for each region, a detailed list of the number of cases subject to submission and the number of submissions/non-submissions is exposed at the bottom, so that the status of non-submission by region can be identified.

Management Guidance Standard Trend

Based on the data of the Management Guidance Report, the trend over the past three years is expressed in a linear graph.

It is possible to judge the validity of the data and the possibility of errors by examining the trend of the management guidance standard report data according to the base year and region.

Cross-verify data between items through the trend graph for each item in the management guidance standard report.

Report generation instruction

Periodic report generation instruction is automatically processed by the scheduler according to the cycle (annual/semi-annual/quarterly), but it is a screen for instructing or re-instructing report generation on an irregular basis.

Instruct the desired financial institution to generate a specific report for a specific base year.

It is possible to check the blockchain information for the report generation instruction.

You can sort by clicking each item in the report creation instruction history list at the bottom.

Electronic financial report management

Search the list of reports submitted by financial institutions using the base year, region, financial institution, report type, period, status, etc. as search conditions.

It is possible to check the blockchain information about the report generation performance of financial companies.

Through reading the report, it is checked whether it complies with the provisions of financial laws and regulations to determine whether it is necessary to re-order the report.

The list at the bottom can be sorted in ascending/descending order by clicking each item.

When searching for a report, the consistency of each list is checked, and in case of violation, the data line is displayed in red.

Notification of law changes

Alarm function that enables automatic recognition in the report system when a change of law occurs in the MRR system

Expose the number of change notices registered within the last 3 days

When clicked, the list of change notices can be viewed in the order of the most recent, and detailed information is displayed when selected.

View report

View reports submitted by financial companies according to the form

When reading the report, the report forgery is verified by comparing and reviewing the hash value of the report data stored in the block chain at the time the financial company generates the report data and the hash value of the report data at the time of viewing.

Explicitly compare two hash values by exposing them at the bottom of the report screen

In the case of a conformity violation report, the details of the violation are exposed at the top of the screen when viewed

Determination of compliance with financial laws and regulations by reading the report

Financial company report screen

Electronic financial report management

Search the list of reports by financial company's report status using the base year, report type, status, etc. as the search criteria.

It is possible to check the blockchain information on the execution of report generation

When generating a report, the MRR system verifies whether the report violates the rules and stores the results together in the DB

Reports created or submitted can be viewed according to the form

Management Guidance Standard Trend

Based on the data of the Management Guidance Report, the trend of the last 3 years is expressed in a linear graph

It is possible to judge the validity of the data and the possibility of errors by reviewing the trend of the management guidance standard report data according to the base year and item

Cross-validation of data between items through the trend graph for each item in the management guidance standard report

View report

View reports generated or submitted by financial companies according to the form

When reading a report, the report forgery is verified by comparing and reviewing the hash value of the report data stored in the block chain at the time the financial company generates the report data and the hash value of the report data at the time of viewing.

Explicitly compare two hash values by exposing them at the bottom of the report screen

By reading the report, it is possible to check whether it complies with the regulations of financial laws and to regenerate the report in case of nonconformity.

Analysis of the impact of changes in laws and regulations

Reporting system system work process when laws change

33 is a structural diagram of a law change logic showing a work process of a reporting system when a law is changed.

When the MRR system transmits information about changes to laws and regulations to the reporting system, the notification alarm is displayed on the report screens of the Financial Supervisory Service and financial companies in the same way so that the person in charge can recognize and check the changed contents.

If the changes in laws and regulations affect the report format, that is, report cycle, submission deadline, report abolition, etc., the relevant information is transmitted to the reporting system so that it is reflected in the automatic report generation instruction program by the scheduler.

From the instruction to generate a report on changes in laws and regulations, the subsequent process proceeds as a general process for performing work.

When changes are made to report output items, detailed information about the changes is received from the MRR system and an alarm is notified on the report screen.

Download the report extraction program generated through machine-executable regulation that reflects the changes in the report items to the financial company system, start the web server, extract and generate report data from the financial company DB again, and store it in the report DB of the Financial Supervisory Service. Save.

You can check the results of adding/changing/deleting report items by viewing the regenerated report due to changes in items.

If there is no change in the report output item, the details of the change are received from the MRR system and an alarm is notified on the report screen.

Those of ordinary skill in the art to which the present invention pertains will understand that the present invention may be embodied in other specific forms without changing the technical spirit or essential features thereof. Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive. The scope of the present invention is indicated by the following claims rather than the above detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalent concepts are included in the scope of the present invention. should be interpreted

110: conversion module 120: extraction module
130: judgment module 140: combination module
210: ontology DB 220: display module
230: modification module 310: table creation module
320: report receiving module 330: report update module

Claims (8)

Ontology DB that divides laws or regulations expressed in natural language into ontology elements through morphological analysis, then converts them into ontology codes (OWL codes; hereafter referred to as ontology codes) and stores them;
a table creation module for generating a mapping request table by mapping ontology codes for each one or more items included in the table form information when the table form information is received from the client; and
A report receiving module that transmits the mapping request table generated through the table creation module to a financial company server, receives report data corresponding to the mapping request table from the financial company server, and stores the received report data in a report DB; includes An interlocking system of ontology and financial DB using mapping tables. According to claim 1, wherein the financial company server,
When the mapping request table is received, the ontology and financial DB interworking system using a mapping table, characterized in that the value stored in the financial DB is matched according to the ontology code for each item. According to claim 1,
When any one of the report data stored in the report DB is selected through the client, the report update module receives from the financial DB corresponding to the selected report data and updates the report; ontology and financial DB using a mapping table, characterized in that it further comprises; of interlocking system. The method of claim 3, wherein the report update module,
An interlocking system between ontology and financial DB using a mapping table, characterized in that the hash value of the updated report data is compared with the hash value stored in the block chain of the corresponding financial company and the final data is stored in the report DB if they match.
(a) dividing laws or regulations expressed in natural language into ontology elements through morphological analysis, converting them into ontology codes (OWL codes; hereafter referred to as ontology codes) and storing them in the ontology DB;
(b) generating a mapping request table by mapping ontology codes for one or more items included in the table form information when the table form information is received from the client; and
(c) transmitting the mapping request table generated through the table creation module to a financial company server, receiving report data corresponding to the mapping request table from the financial company server, and storing the received report data in a report DB; Linking method of ontology and financial DB using the included mapping table. The method of claim 5, wherein the financial company server,
When the mapping request table is received, the ontology code and the financial DB interworking method using a mapping table, characterized in that matching the value stored in the financial DB according to the ontology code for each item. 6. The method of claim 5,
(d) receiving from the financial DB corresponding to the selected report data when any one of the report data stored in the report DB is selected through the client and updating the report; ontology and finance using a mapping table, characterized in that it further comprises; DB linkage method. The method of claim 7, wherein step (d) comprises:
An interlocking system between ontology and financial DB using a mapping table, characterized in that the hash value of the updated report data is compared with the hash value stored in the block chain of the corresponding financial company and the final data is stored in the report DB if they match.

Images