Risk transfer configurator and simulation engine and method thereof for steering and adjusting risk driven portfolio of underwriting subject matter providing forward looking and hindsight measures

Abstract

An automated digital channel is presented to place and manage risk transfers in the reinsurance industry. The digital channel is based on an indicator simulation engine that automatically predicts forward-looking and backward-looking impact metrics based on event parameter values measured for a time-dependent series of physical risk events. The occurrence of the physical risk events is measured based on predetermined thresholds for event characteristic parameters, and the impact of the physical risk events on a particular physical or intangible real-world asset or living target is measured based on impact characteristic parameters. Characteristics of the risk transfers are captured at least in part by means of a parameter-driven branching process that dynamically captures characteristic parameter values and dynamically maps the values to structured characteristic parameters.

Description

TECHNICAL FIELD

[0001] The present invention relates to a parameter driven simulation engine for forecasting forward looking and backward looking indicator metrics based on the parametric nature of the time dependent occurrence probability of physical risk events. It relates to intelligent automated optimization techniques for steering, monitoring and adjusting / optimizing a portfolio of risk driven underlyings and related risk transfer units. More particularly, it relates to a system for the forecasting and exposure based signaling, steering and / or operation of a risk event driven or triggered system, typically but more particularly a system for the automation of underwriting, risk management, risk portfolio steering and signaling, which relates to an improved recognition of the impact of the occurrence of a risk event or catastrophe on a portfolio, i.e. the display of measured catastrophes showing loss impact, and its quantification of the impact forecast or prediction, and / or an improved ability to initiate or trigger appropriate risk mitigating measures to cope with liability risks, and / or an improved scenario based modeling of catastrophe exposure, and / or an improved resource / risk balancing with improved risk charging / cost signaling and optimized loss ratio handling. BACKGROUND

[0002] In all technical fields, there is a general need to evaluate, measure and forecast based on measured parameters and sensory data about future operation or state of real world physical systems, assets or living underlyings. An important factor for such measurement / forecasting is the exposure of e.g. a measured real world physical system, asset or living underlying to an externally occurring risk event, and possibly related to an internal aging process of the real world physical system, asset or living underlying. This is particularly true in automated risk transfer technology. Risk transfer systems heavily rely on the adjustment or calibration of a basic rate measure for each exposure unit determined. The basic rate can significantly change for risks with different characteristics, i.e. the time dependent occurrence probability of a physical risk event. One of the differences between the basic rate measure required in risk transfer technology and the parameters of a typical product usually relies on the fact that the actual impact of a provided risk transfer on a specific basic rate measure is unknown until a predefined risk transfer time period has expired and / or a risk event has occurred. Therefore, the risk transfer rate measure heavily depends on a forecast or forecast measure of the time dependent propagation of the current parameter value of a physical risk event and its possible impact, rather than directly on the current parameter value. Furthermore, the propagation mainly relies on a forecast of the dependency, which lacks a clear handling of the occurrence probability measure, i.e. the risk measure, in a technical sense.

[0003] In the prior art, most of the rates are determined by performing statistical analysis on measured and monitored historical incurred losses based on specific trigger variables of the assets or the underlying of the exposure. The parameters that produce the best forecast are the criteria that set the rate values. In cases where performing historical analysis cannot provide enough statistical leverage, such as for earthquake risk transfers, catastrophe modeling techniques are usually used, but with a large error rate. An automated risk transfer system must be able to achieve both (a) setting rate measures based on specific variables, and (b) determining which variables to apply to a specific risk transfer underwriting asset or underlying. Technically, a base rate provides a measure of the resources required to be associated with an individual risk transfer, i.e. the probability of a physical loss or damage impact due to the occurrence of a physical risk event such as a hurricane or an earthquake, or financially, a base rate provides a measure of the cost (or expense) associated with an individual risk transfer. The rate based allows the risk transfer system to properly weight different transfer risks, i.e. to maintain a balance between the assets or the underlying of the exposure risk and the insured. This structure takes into account the fact that the cost changes with each individual risk transfer. Moreover, different types of costs have different correlations with the total cost of the risk transfer. However, each cost that provides a risk transfer has a different correlation with the risk transfer itself and must be allocated in some way to the underlying or asset from which the risk is transferred. In the prior art, risk transfer costs or expenses are divided into one of two categories, namely those costs that change with the total cost of the risk transfer and those costs that do not change with the total cost of the risk transfer. The problem of allocating these different types of expenses has been solved technically differently in the prior art. At least two variants of the structure used to solve these problems are known in the prior art, in particular 1) the costing method and 2) the labor compensation method. For the automation of risk transfers, the system relies on three important prerequisites: (i) all quantities are measured accurately, (ii) all rates are at the right level, and (iii) the rating structure is scalable and multiplicable. Also, it is important to note that in this context, the exposure unit is the index measure used in the risk transfer rates, i.e. the premium rates. The premium is a measure of the total resources to be allocated with the risk transfer (i.e. the total cost of the risk transfer), usually given by the policy. Thus, the relationship of these measures is given by premium = rate x exposure unit. For example, if the premium is measured in monetary units (e.g. Euros or Dollars) and the exposure or exposure unit is measured in "car years", for example, the index measure of the rate would be measured in "Euros per car year". Therefore, there is a need to provide an automated technical system and method to technically allow a fast evaluation and / or an automated forecast and prediction of a risk transfer or a combination of risk transfers in an automated and accurate manner based on physical measured parameters.

[0004] In the prior art, processor-driven systems with user interfaces for automatic data reception are used for binding contracts between users and digital platforms or channels, which are known in the prior art, in particular via the Internet. In the field of risk transfer technology, such systems or platforms are, for example, automated underwriting (UW) platforms. In order to improve the quality of data acquisition, known systems are usually equipped with verification means in order to check the input data values on the basis of data rules assigned to the data input fields of the user interface and, if necessary, to request corrections via the user interface. In the case of products or services to which a fixed purchase price is assigned, sales contracts can be automatically concluded online by known systems. However, if the subject matter of the contract relates to a service structure / product for which the conditions of the contract cannot be simply assigned, in particular on the basis of individual one-to-one prices, the known systems are only suitable for data acquisition for ordering or applying for services that have to be manually processed later by a professional assistant of the service provider. This means that contracts for services that depend on a number of conditions and factors, for example risk transfers that depend on a number of many and different risk factors and risk transfer conditions, cannot be automatically and online concluded by known systems, nor can such risk transfers or baskets of risk transfers or combinations of risk transfers be dynamically adapted from the user side without manual assistance from the provider side. In known systems, users from different countries and / or language areas can be treated differently by selecting and activating different user interfaces depending on the relevant country or the relevant language area of the user. For example, a graphical user interface in a specific country or language is presented to the user. The existence of a plurality of different user interfaces for different user groups increases the complexity and maintenance costs of the system. For example, general changes to the user interface have to be made in all the graphical user interfaces in the specific countries and languages.

[0005] Disclosed US2018114272A1 shows an automatic, inter-arrival-time-based system that automatically predicts the occurrence of a disaster event and automatically sends signaling to an associated, disaster event-driven or triggered automatic risk transfer system. Physical events are measured and assigned to a historical disaster set that includes event parameters for each assigned event. An event loss set is based on utilizing associated loss measurements and predicted frequencies of the events in the disaster set, each of the events producing a specific set of losses. A wait time between successive events of a time-stamped loss set is captured based on dynamic estimates of the distribution of corresponding inter-arrival-time parameters. The wait time measures the time interval between two successive risk events and captures risk-specific temporal clustering and / or seasonal occurrence patterns. Disclosed US2017161859A1 shows a system based on the following processing steps: capturing parameters of a specific country of a country of exposure risk in relation to stored predetermined criteria; assigning one or more disaster event types to a disaster history table; capturing and storing mapping parameters of a geographic risk map; assigning each of a plurality of selectable disaster financing types to definable cost factors that capture capital costs of the disaster financing type in relation to its application for disaster mitigation; determining expected disaster losses by a loss frequency function and the geographic risk map for various scenarios of occurrence of the natural disaster event types; and preparing a forecast of the impact on the disaster financing types to cover the disaster losses based on the overlay structure, the assigned cost factors, and the determined expected disaster losses. Finally, disclosed US2008065427A1 shows a system for analyzing data collected from sensors monitoring a property. The system uses a computerized process to analyze the data to make property insurance underwriting decisions based on the collected sensor data, the computerized process varying its manipulation of the collected sensor data based on characteristics of the insured property, characteristics of the entity seeking insurance, and / or values of one or more data parameters collected. The system allows automatic formulation of property insurance pricing decisions based on similar dynamic computerized processes. SUMMARY

[0006] The object of the present invention is to allow, on the basis of physical measurement parameter values and data, the systematic capture, measurement, quantification and prospective generation of proper risk and risk accumulation measures associated with risk exposures of physical real-world assets and targets, i.e. the impact of physical events that can occur in a defined future time window, of risk transfers and combinations of risk transfers. Another object of the present invention is to propose a processor-driven system or platform that provides an automatic digital channel for the automatic underwriting and dynamic adjustment of risk transfers between users of risk transfer services and providers of risk transfer services that does not exhibit the drawbacks of known systems. In particular, the object of the present invention is to propose a processor-driven, index system or digital platform that comprises a user interface that can be operated via a data transmission network for users by means of a terminal, comprising data input fields for the input of data relating to the target of the risk transfer, which user interface is available and can be used as a one-stop, end-to-end process for the making, monitoring and adjustment of risk transfers or combinations of risk transfers by users independently of the location or desired target of the contract (service). In particular, another object of the present invention is to propose a processor-driven, computer-based system that comprises a generic user interface that can be flexibly adapted to variable risk transfer conditions and risk transfer types of the automatic binding process without producing changes visible to the service user. The inventive technology used should be able to be easily integrated into other processes, production chains or risk assessment and measurement systems. Finally, the present invention should be able to use data and measurement parameter values from a plurality of heterogeneous data sources. The probability and risk forecasts should allow the capture of various devices and environmental structures, provide precise and reproducible measurements of risk factors and allow the optimization of the impact of the occurrence of associated events of the captured risk events.

[0007] According to the invention, these objects are achieved in particular by the features of the independent claims. Further advantageous embodiments result from the dependent claims and the description.

[0008] According to the invention, the above-mentioned objects are particularly achieved by the inventive automated risk transfer configurator allowing for quickly composing, launching and configuring highly customized secondary risk transfer structures, wherein the automated risk transfer configurator comprises an index simulation engine, wherein a base rate measure and / or a structural mix characteristic of a combination or basket of risk transfers including captured risk exposure units is varied until a desired degree of change in the base rate measure and / or the structural mix characteristic is reached. In particular, the invention relates to the above-mentioned index simulation engine for automatically predicting a prospective and a retrospective impact measure based on a time-dependent series of measured event parameter values of occurrences of physical influencing risk events, wherein the occurrences of the physical risk events are measured based on a predetermined threshold value of an event parameter and wherein an impact of the physical risk events on a specific physical or intangible real-world asset or living target is measured based on an impact parameter associated with the asset or target, at least partially by means of a parameter-driven, rule-based branching process capturing a structured asset / target characteristic parameter of the physical asset or target, the branching process dynamically capturing and mapping the values to the structured characteristic parameter, wherein a plurality of risk transfers associated with occurrences of one or more predetermined risk events influencing the physical asset or target is captured by risk exposure units and the plurality of risk transfers is transferred to a combination of holding risk transfers by means of the captured risk exposure units and wherein a structural mix characteristic of the combination is given by a type of risk measured and captured with the associated risk exposure units and a number of risk transfers allocated, the simulation engine applying a base rate measure to the risk exposure units associated with a specific type of risk transfer based on the event parameter of the risk transfer and the asset / target characteristic parameter of the physical asset or target determined by means of the simulation engine, wherein the base rate provides a cost measure of resources required to cover the risk associated with the specific transfer and wherein a premium of the risk transfer is generated by multiplying the base rate with the number of risk exposure units of the specific risk transfer and the simulation engine dynamically provides the prospective and the retrospective impact measure based on a variation of the base rate measure and / or the structural mix characteristic of the combination including the captured risk exposure units, wherein the prospective and the retrospective impact measure at least comprises a total premium amount associated with the combination of risk transfers and / or a net premium amount given by the total premium amount minus a premium associated with a secondary risk transfer allocated to a transfer portion of the risk exposure units of the combination, and / or a total expected loss measure and / or a CM1 measure. As an embodiment variant, the automated risk transfer configurator and / or the simulation engine can be implemented as an integrated part of a cloud-based application. The cloud-based application can be implemented by a suitable provider as a software as a service (SaaS) on a cloud application.

[0009] The invention has in particular the advantage that it provides an automated electronic digital channel for individually arranging and managing risks and risk transfers between a first risk transfer system or insurer and a second risk transfer system re-insurer, in particular a digital B2B channel for secondary risk transfers between two risk transfer systems (insurer-reinsurer). The invention provides a technical infrastructure for an automated one-stop system for reinsurance solutions for users, including automated underwriting and user-specific data capture, automated claims processing, automated accounting (technical and financial) and automated reporting all in one technical system. The system provides automated secondary risk transfer (reinsurance) liability for all risk-specific areas, e.g. property and casualty risks, life and health risks, any business line or industry risks, single risks, treaty and facultative risks, and cumulative or confl ict risks involving losses exposure of one event spreading over multiple business lines, i.e. related risk structures. The inventive system allows the user to monitor and fully control his risks at any time in a new technical way along the whole value chain. The system also allows for an additional focus on insurance brokers, which can contribute up to 40% to the risk transfer bound by the inventive system, for example. The invention provides a new type of direct and full control and transparency for the user over his risk transfer portfolio, in particular the invention provides early recognition of trends and flexible risk transfer manipulation by means of forward and backward looking indicators and measures. The invention also provides a technical means that can be seamlessly integrated with other technical solutions and systems, e.g. portfolio monitoring platforms.

[0010] The present invention also has the advantage that it provides a technical basis which allows the user to develop a "market ready" strategy significantly faster compared to the technology available in the state of the art systems and technical field. For example, the present invention allows a new risk transfer structure / product deployment within 48 hours by means of the inventive risk transfer product composition unit with higher speed of quote delivery and enhanced referral and placement application compared to the conventional technology systems in the art. The inventive, efficient process and structure allows to keep costs and manpower at a minimum due to the highly automated processes, for example providing a cost leadership of about 2%, a high degree of automation of 90% of the entire value chain, a simplified cost accounting structure, a dynamic pricing structure (for example different price tags for different wordings), easily maneuverable capacity deployment, and efficient online accumulation control for the user, in particular for example implemented as Software as a Service, SaaS. The present invention, implemented as a digital, electronic and automated channel, allows to immediately inform the underwriting request if it has no qualification for an automated processing, otherwise the present invention provides at least an offline channel for risk transfer. For the user, the present invention provides an easy to use risk transfer platform, where the user is able to manage his risk transfer in a fast and efficient way at any time he wants. The system provides a seamless data import by the user's chosen channel (electronic reinsurance, automated insurance broker platform, via Application Programming Interface (API), email transmission, or semi-automated via user interface, where the user's time spend and administrative workload is greatly reduced by automation, and where the system allows to provide efficient digital user support (for example Chatbots). Finally, the present invention allows to leverage existing platforms and applications, and is scalable and technically integrable without duplication. The present invention provides a platform which covers the entire end-to-end process, suitable for internal and external use. Due to its technical flexibility, the present invention can also be implemented by a mobile application, in particular a cloud based implementation provided to the user. BRIEF DESCRIPTION OF DRAWINGS

[0011] The present invention will be explained in more detail below based on examples and with reference to the drawings, in which:

[0012] Figure 1A block diagram illustrating an automatic end-to-end process according to the present invention is shown, which provides an efficient, automatic online risk placement, claims and accounting channel for users, with a complete electronic solution for automatic underwriting construction. Reference numeral 2 denotes an automatic end-to-end process, 21 denotes an automatic underwriting process by means of a rule-based branching process, 211 denotes creation submission, 212 denotes receiving and binding quotes, 213 denotes modifying and updating commitments, 22 denotes a technical accounting process, 221 denotes pre-determined premium, 222 denotes suggesting new claims, 223 denotes pre-booking and updating claims, 224 denotes correcting premium, 225 denotes submitting account statements, 23 denotes a financial accounting process, 231 denotes suggesting and / or requiring payment, 232 denotes seamless pairing, and finally 233 denotes setting of accounts. The proposed invention and method provide fast and easy access to first and secondary risk transfer underwriting, technical and financial accounting. The invention allows for reduced technical and administrative input and cost of managing the risk transfer portfolio. It also provides fast access and automatic capacity approval for medium-sized single risks or credits. Finally, the invention allows for reduced technical and administrative time by providing an easy-to-use and efficient online risk placement, claims and accounting channel for customers, which is available 24x7, can be fed through a management dashboard, and allows users to have full control over all accounting and claims functions. The invention provides an automatic one-stop solution, which covers a complete end-to-end process for reinsurance of a medium market risk portfolio. The invention allows for consistent underwriting guideline structures for the entire technical process, ensuring consistent response to users' risk submissions with full control and transparency over the portfolio.

[0013] Figure 2 A block diagram illustrating an example risk transfer setup for capturing characteristic data associated with a risk transfer is shown. It shows an example sample risk information for a proportion product of assets captured at a specific location / region.

[0014] Figure 3A block diagram illustrating an example of a rule-based underwriting process for an electronic platform or system of the invention is shown. This process involves the automatic, risk-transfer-specific data capture of characteristic data of physical assets or objects through a parameter-driven branching process. This parameter-driven branching process dynamically captures characteristic parameter values ​​and dynamically maps these values ​​to structured characteristic parameters. Reference numeral 3 indicates a rule-based underwriting process, 31 indicates a standard rule-based underwriting process, 311 indicates an automatic rule-based underwriting process, 3111 indicates a process where the triggering parameters are compatible with the triggering rules, 312 indicates a semi-automatic rule-based underwriting process, 3121 indicates a process where several parameters are incompatible with fixed triggering rules, 32 indicates a non-standard rule-based underwriting process, and finally, 321 indicates a non-standard underwriting process that does not include automatic pricing. For example, there may be 92 different asset risk transfers acquired via the process of the invention (e.g., 63 proportional, 28 non-proportional, and one parameterized). In the context of this invention, risk transfer structures or products are understood as risk transfer structures triggered by business scope, business type, and market / country (e.g., assets, NP, Belgium).

[0015] Figure 4 A schematic diagram illustrating an example of generating forward and backward impact metrics as the output of the simulation engine 10 of the invention is shown, based on multiple data characteristics of risk transfer behavior and fac business. For all risk transfers executed by the system 1 of the invention, the customer submits the risk via the system user interface; all risks are specified by the user based on approximately 20 risk characteristic attribute parameters. Throughout the underwriting process, the system is based on structured data. All submitted and verified submission data is stored in a structured database. This means that risk information for both bound and unbound risk transfers is directly available. The system provides a parameter-driven underwriting process that captures characteristic data: standard risk transfers are underwritten automatically or semi-automatically based on a complex set of rules defined by the underwriting process. If all conditions are met, a quote is immediately made for the business. If some conditions are not met, the risk transfer request is further considered by the managed underwriting desk or expert system. As a variation of the embodiment, the system can be implemented to accept user rate offers; that is, for some products, the offer can provide the user's willing rate for allocating risk transfers, providing an understanding of the gap between the willingness to pay and the actual cost calculation generated by the system of the invention. Figure 4As shown, the system provides forward and backward looking metrics output by providing the following means: (1) as-if scenario: a key to portfolio manipulation, the simulation engine identifies areas (base rates, business mix) where the invention can act; (2) impact assessment: the simulation engine allows users to assess the impact of changes on the portfolio before it is actually launched in the real world market. Figure 4 A graph showing forward and backward looking metrics generated by the simulation engine in case of a change in base rate factors is shown. In other words, the simulation engine forecasts metrics to answer the question of what would be the impact on the current risk transfer portfolio if the base rates change. In the inventive method and process, the user of the simulation engine is enabled to select the desired level of change in base rates. Subsequently, the impact on portfolio indicators gross written premium (GWP), net written premium (NWP), expected loss and CM1 is assessed. In the example shown, a 10% reduction in base rates for 3 different 1stPIC codes (management, business services, public utilities; chemical and pharmaceutical; retail, trade, storage facilities) is shown. With respect to granularity, the sensitivity can be assessed and compared for each level (risk transfer portfolio, product, PIC level 1-3) and by underwriting year. Figure 4 A graph showing forward and backward looking metrics generated by the simulation engine in case of a change in base rate factors is shown. In other words, the simulation engine forecasts metrics to answer the question of what would be the impact on the current risk transfer portfolio if the base rates change. In the inventive method and process, the user of the simulation engine is enabled to select the desired level of change in base rates. Subsequently, the impact on portfolio indicators gross written premium (GWP), net written premium (NWP), expected loss and CM1 is assessed. In the example shown, a 10% reduction in base rates for 3 different 1stPIC codes (management, business services, public utilities; chemical and pharmaceutical; retail, trade, storage facilities) is shown. With respect to granularity, the sensitivity can be assessed and compared for each level (risk transfer portfolio, product, PIC level 1-3) and by underwriting year.

[0016] Figure 5 A graph showing again a schematic illustration of forward and backward looking metrics generated by the simulation engine in case of a change in base rate factors according to the invention is shown. Again, the simulation engine forecasts metrics to answer the question of what would be the impact on the current risk transfer portfolio if the base rates change. Figure 4 A graph showing again a schematic illustration of forward and backward looking metrics generated by the simulation engine in case of a change in base rate factors according to the invention is shown. Again, the simulation engine forecasts metrics to answer the question of what would be the impact on the current risk transfer portfolio if the base rates change. Figure 5 A change in base rates ranging from -50% to 50% is shown on the x-axis. On the y-axis, the impact on portfolio indicators gross written premium (GWP), net written premium (NWP), CM1 and the number of binding contracts (NR) is shown. A slight increase in premium leads to an immediate decrease in binding risk transfer contracts. However, large risk transfer contracts are lost due to a rate increase of about 15%. If the rate is decreased, additional contracts are bound. With respect to granularity, the sensitivity can be assessed and compared for each level (risk transfer portfolio, product, PIC level 1-3) and by underwriting year by means of the simulation engine.

[0017] Figure 6 A graph showing again a schematic illustration of forward and backward looking metrics generated by the simulation engine in case of a change in base rate factors according to the invention is shown. Again, the simulation engine forecasts metrics to answer the question of what would be the impact on the current risk transfer portfolio if the base rates change. Figures 4-5 A graph showing again a schematic illustration of forward and backward looking metrics generated by the simulation engine in case of a change in base rate factors according to the invention is shown. Again, the simulation engine forecasts metrics to answer the question of what would be the impact on the current risk transfer portfolio if the base rates change. Figure 6A predictive measure is shown that allows to compare costed rates with underwriting rates (volume weighted). A value of 30% means that the rates provided by the customer are on average 30% higher than our costed rates. A negative value means that the underwriting rates are on average lower than the costed rates.

[0018] Figure 7 A diagram is shown that schematically illustrates an example of the generation of forward and hindsight measures by the simulation engine in case of a change of the risk transfer basket or portfolio's risk transfer mix. In other words, the simulation engine forecasts measures to answer the question what would be the impact on the current risk transfer portfolio if the risk transfer mix would change. In this example, the user of the simulation engine selects a change of the volume of risk transfer on the required level. Subsequently the impact on the portfolio indicator measures, gross written premium (GWP), net written premium (NWP), expected loss and CM1 is generated by means of the simulation engine. Figure 7 Figure 7 A change of 5% in the management line, a decrease of 5% in the food line and the exclusion of the impact of risk transfers with a negative CM1 (power, telecom, textile, wood) is shown. With respect to granularity, the sensitivity can be assessed and compared per level (risk transfer portfolio, risk transfer structure (product), PIC level 1-3) and by underwriting year.

[0019] Figure 8 A diagram is shown that schematically illustrates an example of the generation of forward and hindsight measures by the simulation engine in case of a change of the risk transfer basket or portfolio's basic rate factors and risk transfer mix. In other words, the simulation engine forecasts measures to answer the question what would be the impact on the current risk transfer portfolio if the basic rates and the risk transfer mix would change. The user of the simulation engine selects a change of the volume of business and a change of the basic rates on the required level. Subsequently the impact on the risk transfer portfolio indicator measures, gross written premium (GWP), net written premium (NWP), expected loss and CM1 is generated by means of the simulation engine.

[0020] Figure 9 A diagram is shown that schematically illustrates an example of the simulation engine integration. In this embodiment variant, the simulation engine is implemented as an integrated part of the risk transfer portfolio monitor and management platform as an additional functionality. It is thus an integrated part of the risk transfer portfolio analysis and forecasting framework. This electronic solution allows easy access and use by the risk transfer portfolio monitor and management platform and / or the underwriting system and platform.

[0021] Figure 10 An example of a location in the United States is shown, where typically street address information can be captured, and where the system 1 can retrieve a virtual view of the asset, for example with Street View.

[0022] Figure 11a And​11b Cumulative losses are shown, i.e. losses before the insurance condition applies. Figure 11a is the cumulative loss of the example asset rated based on the set of primary attributes, while Figure 11b is the cumulative loss of the example asset rated based on the set of attributes retrieved from the exposure database 2151.

[0023] Figure 12a and 12b The attributes of the data records 21511,...,2151i are shown, which attributes can be grouped, for example, into geographical characteristics, physical characteristics, flood physical characteristics, storm physical characteristics, earthquake physical characteristics, and expert attributes, as from Figure 12a and 12b As can be seen, these groupings represent, for example, the labels of the forward modeling module 21532. Figure 12a A screenshot of the example location 1, data records 21511,...,2151i, geographical location labels, is shown, which shows the geographical input and the geocoding data. Figure 12b A screenshot of the example location 1, data records 21511,...,2151i, attribute data labels, is shown. In this particular case, the following parameters can be retrieved from the exposure data intelligence 215: (i) occupancy level 1; (ii) occupancy level 2; (iii) primary structure type; (iv) detailed structure type; and (v) design year.

[0024] Figure 13a and 13b A view of locations belonging to the same street address is shown, in particular, Figure 13a in Street View, Figure 13b in satellite view. Both buildings are mapped to the same address. In this case, the majority vote does not lead to the desired result, unless better clustering logic is implemented. A possible solution is to consider matching all available attributes from all clustered records.

[0025] Figure 14a and 14bThe technical matching problem of two locations based on latitude and longitude coordinates is illustrated, where the matching can be an efficient pre-processing / refinement step for address matching, mainly because it allows to overcome address formatting issues: once the search is narrowed down to the grid cells 215221 around the asset / target of interest 12, the location parameters 215112 of the two locations can be matched based on the house number or other attributes only. A technical problem arises when choosing the scale 215222 of the search grid cells 215221. Usually the result is that it is not large enough to encompass both [Lat, Lon] tags, especially when matching a large asset with a large lot, for example: 3860 W Peterson Ave, Chicago, IL 60603, USA Figure 14b is a StreetView; Figure 14a is a satellite view.

[0026] Figure 15 The example illustrates the integrated OSM (OpenStreetMap) default geocoding processing module 216 of the system 1, by means of which interface it allows forward and reverse geocoding at different levels (building / street / district / suburb / county / state...). It uses NLP for address standardization and can perform house number interpolation when not available by default. For example, in the USA, the Topologically Integrated Geocoding and Referencing System (TIGER) data produced by the US Census Bureau can cover house numbers and roads well.

[0027] Figure 16 The example illustrates the user interface of the Overpass API (Application Programming Interface). In this case, the system 1 is implemented to query the OSM database for all other components (nodes, ways and relations) by their location, geometry, tags and relation to the Overpass API (Application Programming Interface).

[0028] Figure 17 and Figure 18 Validation examples of the raw combined data 215113 in 3 ways are illustrated: (a) raw combined data 215113 addresses produce OSM [Lat, Lon], (b) raw combined data 215113 [Lat, Lon] to OSM (Rev) addresses; and (c) coordinates matching to footprint. In Figure 18 the example, the footprint matching is visualized on a map. This is an example of coordinates tagging just "close enough" to the correct building.

[0029] Figure 19The example shows the matching of coordinates to OSM coverage areas. In this step, the system 1 determines whether any of the found locations belong to a building coverage area. The query is built with the modified Overpass Python module. In a first step (I), all building coverage areas are retrieved within a certain grid cell, e.g. within a 100m radius of the coordinates of the original combined data 215113, with an Overpass query (all ways and relations with the tag "building"). The retrieved geometries are processed with the GeoPandas and Shapely libraries (GeoPandas allows working with geospatial data in Python). GeoPandas extends the data types used by Pandas to allow spatial operations on geometrical types. The geometrical operations can be performed, for example, by Shapely. GeoPandas also computes the convex hull of each coverage area to simplify the shape, based on Fiona for file access and Descartes and Matplotlib for plotting. (II) The algorithm can subsequently perform a search for polygon points on both the coordinates of the original combined data 215113 and the OSM coordinates in all obtained shapes. If the first search returns only one polygon, the match is labeled "exact". Otherwise, all matching returns are returned without the "exact" label. In case of no match, a buffer zone is added to all shapes and the search is repeated. (III) If no match is found, the buffer zone is increased and the search is repeated. To keep track of the uncertainty, the size of the buffer zone is added according to each matching return (see Figure 19 Steps I-III).

[0030] Figure 20 The example shows two exemplary histograms, where the upper one is a histogram of the distance error between the coordinate pairs of the original combined data 215113 and the OSM coordinates within a range of 100m. 85% of the geocoding results fall within this range. The lower histogram shows a histogram of distance errors with a distance greater than 100m, representing 15% of the results.

[0031] Figure 21 A general cluster tree is shown that visualizes the agglomerative and divisive clusters.

[0032] Figure 22 The original purpose of the clustering is shown: to deduplicate the records 21511,..., 2151i of the original combined data 215113.

[0033] Figure 23 One of the proposed clustering levels is shown, where the streets are at the root level.

[0034] Figure 24An example clustering hierarchy is shown with the locations at root level. Clusters defined by their geometrical shape are at different levels -> Clusters cannot be confused, there is no chance of duplication. The applied "bottom-up split clustering" method, for example, can lead to Figure 24 a graphical visualization. In this approach, the granularity increases with the addition of each cluster node (before adding a cluster, its parent has to be known), so that it resembles a "top-down" approach. At root level, there are clusters of locations formed by road junctions, neighbor clusters or block clusters. Clusters at the next level are formed by single buildings inside the root clusters. At the lowest level, there are single risk / insurance items with defined [Lat, Lon] and address, which can basically be seen as a record 21511,..., 2151i of the de-duplicated raw combination data 215113. Figure 24 The graphical visualization also shows examples of meaningful cluster attributes at each level.

[0035] Figure 25 A drivable road network extracted from OSM (using the OSMnx python module) is shown for creating root level clusters.

[0036] Figure 26 A closed polygon as root level cluster is shown visualized on a map.

[0037] Figure 27 A coverage area of Washington D.C. derived from satellite images is shown.

[0038] Figure 28 Using OSM as a source for combination data enrichment, from which metadata tags and key values of interest can be retrieved (i.e. for building key values, we can find out its type / value, similarly for industry key values - industry type).

[0039] Figure 29 A possible split of the raw combination data 215113 into building and low level risk attributes is shown. When new risks need to be added in the scheme or lookups / aggregations are to be performed at a specific level, the hierarchy explained in Figure 29 is particularly useful.

[0040] Figure 30 A location intelligence engine 2156 of the machine-based exposure data intelligence 215 is shown. By implementing queries to a database (which can be accessed as a web application through a suitable user interface), the usage and access of the exposure database 2151 can easily be done in a more user-friendly way, which enables the user to look up clusters by address and coordinates and browse the respective attributes with the help of the location intelligence engine 2156 (see Figure 30 ).

[0041] Figure 31 An example of such an encoding scheme is shown. Each index corresponds to a character at the corresponding index position in the encoding alphabet, e.g.: (i) negative indices: 2 3 4 5 6 7 8 9 CF, (ii) positive indices: GHJMPQRVX.

[0042] Figure 32a and 32b Such a cell can be encoded with one of 20 characters to obtain 5m precision on a 100m range, as shown. Individual points / sub-cells can be defined, e.g., as shown in Figure 32a and areas can be defined by adding multiple sub-cells together, as shown in Figure 32b DETAILED DESCRIPTION

[0043] Figures 1 to 32b A possible implementation architecture for embodiments of the digital platform and the metrics simulation engine 10 of the invention for automatically predicting forward looking and backward looking impact metrics based on measured event parameter values of a time dependent series of physical impact events, and the automatic risk transfer configurer and risk transfer portfolio management platform 1 are schematically shown. As shown in Figure 1 the automatic end-to-end process 2 of the invention provides users with an efficient, automated online risk placement, claims and accounting channel that is a complete electronic solution for automatic underwriting business construction.

[0044] ​The automated risk transfer configurator and risk transfer portfolio management platform (or system) 1 provides an automated, multi-channel, end-to-end risk transfer product configuration process for configuring, launching and processing customised second tier risk transfer structures. The digital platform and automated risk transfer configurator thus allow for the rapid composition, launch and configuration of highly customised secondary risk transfer structures. The system 1 provides an automated risk transfer product layout as a first online channel, which comprises a parameter-driven, rules-based underwriting process for creating a portfolio of customised second tier structures. The system 1 provides an automated technical accounting process 22 as a second online channel, and the system 1 provides an automated financial accounting process 23 as a third online channel. The system 1 comprises a product configurator 214 for providing automated underwriting by means of a rules-based branching process 21. The product configurator 214 comprises at least four building blocks: a first structured block for setting coverage area parameters 2141 of a risk transfer product, a second structured block for setting business scope parameters 2142, a third structured block for setting risk transfer type parameters 2143 and a fourth structured block for setting risk information parameters 2144. To capture risk information parameters 2144, the product configurator 214 comprises a machine-based exposure data intelligentisation process 215, which enables it to automatically identify the unique risks of a target 12 based on the precise location of the target 12. The system further comprises an index simulation engine 10 for automatically predicting forward-looking and backward-looking impact metrics 101 based on a time-dependent series of measured values of event parameters 111 of the occurrence of physical impact risk events 11. The occurrence of a physical impact risk event 11 is measured based on a predefined threshold of event parameters 111 and the impact of a physical impact risk event 11 on a particular asset or target 12 is measured based on impact parameters 112 associated with the particular asset or target 12. The system 1 comprises a graphical user interface of a portfolio analysis framework 6, which provides a dynamic representation 61 of a risk transfer portfolio or basket 14, wherein the index simulation engine 10 forms an integral part of the portfolio analysis framework 6. By means of the index simulation engine 10, the dynamic representation of the risk transfer portfolio or basket 14 provides forward-looking and backward-looking insights to the user, thereby enabling portfolio manipulation by identifying key areas of the risk transfer portfolio or basket 14 and the impact of possible changes that can occur before entering the market on the underwriting.

[0045] As an embodiment variant, the digital platform comprises a customer rate offer module 7, wherein the user is enabled to input and offer a rate he is willing to pay by means of the customer rate offer module 7, thereby allowing the system to capture insights into the gap between the willingness to pay and the cost accounting generated by the digital platform.

[0046] Machine-based exposure data intelligentisation process 215

[0047] The machine-based exposure data intelligence processing 215 comprises an exposure database 2151, e.g. based on a SRX+ database scheme, comprising a plurality of data records 21511,..., 2151i holding property parameters 215111 of assets and / or targets 12, respectively, with assigned geographical location parameters 215112. The exposure database 2151 may, for example, be implemented as a globally centralized geographical database providing a standard repository for geographical data or the like. In particular, the exposure database 2151 stores pools or portfolios of assets and / or targets 12 of risk exposure, wherein portfolios of targets 12 are assigned to specific users. Further, the machine-based exposure data intelligence processing 215 comprises an EDI engine 2153 (exposure data intelligence processing engine) providing modeling and rating of risk based on exposure, e.g. Nat Cat modeling. Further, the machine-based exposure data intelligence processing 215 comprises an EDI engine 2153 (risk data intelligence processing engine) providing risk modeling and rating of risk based on risk, e.g. Nat Cat modeling. The exposure data intelligence processing 215 comprises appropriate application programming and graphical user interfaces (API / GUI) or other data interfaces. If the machine-based exposure data intelligence processing 215 is mainly focused on natural catastrophe (Nat Cat) processing, it can also be denoted as NCEDI (Nat Cat exposure data intelligence). Thus, the EDI engine 2153 can provide lookup service access 21531 for users, e.g. based on clustering of the exposure database 2151 and data records 21511,..., 2151i, wherein an automated identification of location-specific risks can be assessed by users based on the precise location of assets and / or targets 12. For providing automated modeling and rating, the EDI engine 2153 may, for example, comprise a forward-looking modeling module comprising, for example, a natural catastrophe risk modeling structure. The modeling structure may, for example, generate loss distributions for major risks, e.g. earthquake events, storms and floods, against their geographically largest exposure. For the loss metrics used, probabilities and combinations of economic and insurance values can be used to assess the annual expected total loss and insurance loss caused by each risk in a particular year. The modeling scenarios with expected loss estimates can be supplemented by data from external sources, e.g. global assessment data of the United Nations Office for Disaster Risk Reduction. The machine-based exposure data intelligence processing 215 comprises a clustering module 2152 for clustering the stored assets / targets 12 of the exposure database 2151 in relation to the assigned geographical location parameters 215112 of the assets / targets 12. The data records 21511,..., 2151i of the stored exposure database 2151 may, for example, cover a large range of worldwide information and measurement data, including data on countries, states, counties, zip codes and communities as well as global natural catastrophe measurement data.In case of triggering inconsistencies of data records 21511,..., 2151i with the same assigned geo-location parameter 215112, different data records 21511,..., 2151i of the exposure database 2151 with the same assigned geo-location parameter 215112 are matched and mutually calibrated.

[0048] The machine-based exposure data intelligent processing 215 can further comprise a user data interface 2154, which is accessible via a client or access terminal (or mobile device) 5 to input location data 215112 via a GPS module 54 or optical sensor and / or camera 55 of the mobile device 5. The mobile device 5 can for example be implemented as a mobile phone or PDA computer (personal digital assistant) 53. The user can for example scan the insurance asset 12 by means of the mobile device 5 using data transmission to the digital platform of the GPS module 54 or optical sensor and / or camera 55. The machine-based exposure data intelligent processing 215 can for example comprise a cross-level analysis module 2155, which provides identification 21551, analysis 21552 and visualization 21553 of a large risk pool, wherein the risk pool comprises a plurality of the objects 12 of the exposure database 2151, wherein different levels and channels comprise at least admitted risk transfer and / or contractual risk transfer and / or customized corporate direct risk transfer, and wherein the risk of the assets / objects 12 is analyzed for different levels and channels based on the attributes 215111 and locations 215112, thereby allowing automatic tracking of risk accumulation and / or capacity thresholds.

[0049] The clustering module 2152 of the machine-based exposure data intelligent processing 215 can for example comprise an automatic address matching 21521 based on latitude and longitude coordinates 2151121 / 2151122 of the locations, wherein for clustering the search is narrowed down to grid cells 215221 around the asset / object 12 of interest, to a scale 215222 where two locations 215112 can be matched based on house numbers or other location related attributes only. For clustering, the clustering module 2152 can for example use adaptive cell size and / or shape 215223, which depends on the local residential / construction density. Alternatively, for clustering, the clustering module 2152 can further use accessible building footprints to check whether the latitude / longitude labels are surrounded by the footprint of interest, wherein any latitude / longitude coordinate 2151121 / 2151122 is mapped to a unique building and / or associated with a site.

[0050] In the risk transfer system, the exposure database 2151 is usually built from customer portfolios over years. Since contracts are usually renewed every year for the same asset / subject 12, it can appear multiple times in the database 2151 but sometimes with different sets of attributes. This technically leads to a lookup problem since there is no unique asset identifier. This problem is solved by clustering those attributes by location, allowing a lookup service. Moreover, it is often known the street address, the type of building and sometimes the type of construction, the type of roof and the exterior walls of the insured building, i.e. it can be retrieved from data sources. The invention is able to provide appropriate data enrichment, for example by means of the forward modeling module 21532. Taking as an example a US location, at which it is usually possible to capture street address information and the system 1 can retrieve a virtual view of the asset, for example with Street View (see Figure 10 ). For data enrichment, the invention combines various heterogeneous data sources as internal data sources of the insurance system, for example the exposure database 2151, and external data sources as the “GeoFacts” dataset from Google, to complement the data used for modeling, for example for assets and subjects 12. If a loss simulation is performed on the example building shown in Figure 10 by means of the EDI engine 2153 and / or the forward modeling module 21532, once with the minimum attributes, once with the information retrieved from the system 1 and the exposure data intelligence to enrich, it is possible to compare the expected losses of the two approaches. In Figure 11a and Figure 11b , the cumulative losses, i.e. the losses before the application of the insurance conditions, are shown, in which Figure 11a shows the cumulative losses of an example asset 12 rated based on the main set of attributes, Figure 11b shows the cumulative losses of an example asset 12 rated based on the set of attributes retrieved from the exposure data intelligence 215 (denoted as NCEDI in Figure 11b ). The data records 2151 1,..., 2151 i can for example take a format encoding a predefined set of attributes that can take specific values. These attributes can be grouped as geographical characteristics, physical characteristics, flood physical characteristics, storm physical characteristics, earthquake physical characteristics and expert attributes, as visible from Figure 12a and 12b , which represent for example the labels of the forward modeling module 21532. Figure 12a shows a screenshot of an example location 1, data records 2151 1,..., 2151 i geographical location labels, which shows the geographical input and the geocoded data. Figure 12bAn example location 1, data record 21511,..., 2151i attribute data tab screen shot is shown. In this particular case, the following parameters can be retrieved from the exposure database 2151 : (i) occupancy level 1, (ii) occupancy level 2, (iii) main structure type, (iv) detailed structure type, and (v) design year.

[0051] During the validation and enrichment process, instead of system 1 being able to automatically identify unique risks through its precise location, the exposure data intelligence 215 automatically avoids user errors in inputting into the exposure database 2151. Moreover, system 1 allows mapping of ownership from multiple submitted policies: for example, if cluster K belongs to user Z in submission X, the owner of the policy is unknown in submission Y, this can be looked up via a link back to cluster K. As an embodiment variant, in the smart home technology field, system 1 provides a data interface that allows users to obtain / purchase risk transfers directly from the App and benefit from appropriate rates by integrating their IoT data into the exposure database 2151. System 1 allows providing user access as simple as users being able to use a smartphone (with GPS and camera capabilities) to determine a precise location and scan their insured items. This can for example involve establishing a risk index of assets for better loss estimation.

[0052] As another embodiment variant, the exposure data intelligence 215 (NECDI) allows creating a network of asset locations that provides identification, analysis, and visualization of a global pool of risks. The network of asset locations can for example be used as a basis for analyzing risks through different levels (clusters) of attributes and locations and allows better tracking of risk accumulation and capacity: for example, the same risk can be split through multiple channels to a second level risk transfer system, i.e. a reinsurance system: via admitted treaty reinsurance business or via company tailored direct solutions risk transfer / insurance. By enabling system 1 to track each risk from different sources, this allows tracking technically the capacity of the reinsurance system with respect to the risk. For example, when calculating the capacity for a given building and through predefined rules or boundary condition parameters, the reinsurance system cannot attempt to take a higher capacity than 100M, the reinsurance system must be able to look up if it participates in other risks in the same building and adjust the exposure so that the reinsurance system does not exceed its predefined capacity limit.

[0053] With respect to the combined data cleansing and location verification process of the exposure data intelligence processing 215, it was discussed above that the items returned from the exposure database 2151 and the exposure data intelligence processing 215 can not have precise locations assigned through [Lat, Lon] or address (i.e. markers set on roads or parking lots rather than actual assets). This can be due to human error during input or due to inaccurate / inconsistent geocoding, for example. The difficulty of verifying geographic data can be illustrated in the following examples, for example:

[0054] (A) Street address verification problem: In Figure 13a and 13b , the street address for both buildings is: Chase Plaza, 10 South, Chicago, IL, USA, ZIP Code: 60603 Figure 13a is Street View; Figure 13b is satellite view): (i) Chase Bank tower, (ii) Public Art Chagall’s Four Seasons. The technical problem here is that both buildings are mapped to the same address (see Figure 13a and 13b , which show satellite views of locations belonging to the same street address). Thus, (i) GeoFacts returns the Chase Bank tower with 74 floors, (ii) clustering by the clustering module 2152 (by majority vote) returns the Public Art gallery with 1 floor, and (iii) the exposure database 2151 returns only the occupancy level, i.e. “commercial building > 30 floors” or “art gallery”. The technical problem is that the Public Art gallery appears more frequently in the exposure database 2151 than the Chase Bank tower. In this case, majority vote (i.e. when the most frequently occurring attribute value for a given cluster is chosen as the dominant and most representative for the entire cluster) does not lead to the desired result, unless better clustering logic is used. As a solution, the system 1 considers all available attributes from all clustered records for matching and receives the correct result.

[0055] (B) [Lat, Lon] Validation issue: matching two locations based on their latitude and longitude coordinates can be an effective pre-processing / refinement step for address matching, basically because it allows to overcome address formatting issues: once the search is narrowed down to the grid cells 215221 around the asset / target of interest 1212, the two locations 12112 can be matched based on the house number or other attributes only. A technical issue arises when choosing the scale 215222 of the search cells 215221. The usual outcome is that it is not large enough to encompass both [Lat, Lon] tags, especially when matching a large asset with a large plot, for example: 3860 W Peterson Ave, Chicago, IL 60603 Figure 14b is a Street View; Figure 14a is a satellite view): (i) Felician Sisters Convent, (ii) Church / religious building, (iii) large asset. The technical issue is that the Lat / Lon can be mapped to (i) a mailbox on the road or (ii) a real building 100m away. As an embodiment variant, the system 1 uses adaptive cell size and shape 215223, which depends on the measured local residential / building density. As another variant, the system 1 uses the available building footprint to check if the [Lat, Lon] tag is encompassed by the footprint of interest. In practice, the technical advantage of doing so is to allow mapping any [Lat, Lon] coordinate to a unique building and linking them to a place (if useful, for example, for industrial sites). Note that these are just two examples, but they can be representative of many locations in the exposure database 2151. They show the technical need to organize, validate and pre-process the combined data before clustering. In summary, the technical improvements of the system 1 and of the exposure data intelligence 215 related to the content of the exposure database 2151 can be classified into the following categories: (i) cleaning and deduplication of the raw location data, (ii) re-geocoding of the location data, (iii) improvement of the clustering hierarchy and logic, and (iv) visualization of the data of the exposure database 2151 in a web application or another graphical user interface.

[0056] Regarding the technical validation of the location data 215112, the large size and the continuous growth of the combined database make it technically significant to keep it organized, accurate and efficiently queryable. The organization of the initial data is technically absolutely critical. To validate this initial data, the system 1 proposes to set up and implement new geocoding service processes, different parsing algorithms for the raw data and appropriate visualization tools to view the results.

[0057] The system 1 has in particular the advantage of automatically ignoring files containing corrupted lines, e.g. having more entries than the number of header columns (possibly related to faulty special character escaping). Other entries have to be de-duplicated, etc.

[0058] Hence, the intelligent de-duplication of records is implemented by the system 1. Furthermore, the validation is also handled by the system 1, although the validation of millions of locations is technically not a simple task. For such a large amount of data, it is technically generally not reasonable to use external data sources as the current geocoding provider (Google). Hence, bulk geocoding requires an integrated solution as well as geocoding technology and servers. The present invention technically uses an OpenStreetMap based bulk geocoding approach. Hence, the system 1 builds its own geoserver based on OpenStreetMap (OSM) data, which comes with the following benefits: (i) it is free, open source, locally run and has no query limits, (ii) its database is frequently updated and steadily growing, (iii) it includes data from many publicly available, global and local sources (government, Wikipedia, etc.) as well as contributions from users, (iv) it provides forward and reverse geocoding solutions, (v) it supports advanced query logic for 1000s of location features (tags), (vi) it technically allows queries for points, polygons and relations. At this point, it is important to note that the present system 1 can easily be integrated in other technical solutions.

[0059] As an embodiment variant, the system 1 uses an integrated OSM (OpenStreetMap) default geocoding processing module 216 and interface (see Figure 15 ) which allows forward and reverse geocoding at different levels (building / street / district / suburb / county / state...). Moreover, this variant utilizes NLP to implement its address standardization and can perform house number interpolation when the default is not available. In the US, a good coverage of house numbers and roads is available, e.g. from the Topologically Integrated Geophysi cal Coding and Referencing System (TIGER) data which can be produced from the US Census Bureau.

[0060] The system 1 can be implemented and designed to only process address related queries, however, as a variant, it can also be implemented to query the OSM database for all other components (nodes, ways and relations) by their location, geometry, tags and relation to the Overpass API (Application Programming Interface). Figure 16An example shows a user interface for Overpass queries. The Overpass API can provide various search (i.e. query) possibilities. The results of a search or query can be displayed directly on a map, but can also only retrieve data. The Overpass API is implemented as a read-only API that serves custom-selected parts of the OSM map data. It functions as a database on the web: system 1 sends a query to the API and takes back a dataset corresponding to this query. The Overpass API provides optimized access to system 1, which in many cases requires multiple elements, both selected by search criteria, e.g. location, type, tag attributes, proximity, or combinations thereof, of the subject. Thus, the Overpass API functions as a database backend for various data retrievals with respect to system 1.

[0061] System 1 can for example comprise 3 ways of location verification (see Figure 17 ). Here, by location verification, it is understood the verification of street addresses and coordinates. This comprises the following steps:

[0062] (a) Address -> OSM [Lat, Lon] of raw aggregated data 215113: determining the coordinates belonging to the addresses of raw aggregated data 215113. This can be achieved for example by using the GeoPy module (GeoPy is a Python 2 and 3 client for several geocoding data services, GeoPy allows Python developers to locate the coordinates of addresses, cities, countries and landmarks globally using third-party geocoders and other data sources) with a local geocoding processing endpoint and some custom scripts. It is important to note that this step can require an intelligent pre-processing of the addresses stored in raw aggregated data 215113, because: (1) street addresses are not standardized, they comprise information about street name, house number and apartment, but not city, district or postal code. This problem can be technically solved by standardizing the addresses with an address module (e.g. the address Python module) in order to keep or filter only the street and house number. The geocoding results can be refined by including postal code, suburb, district and city attributes that can be resolved from reverse geocoding, as described below. (2) it contains addresses with a range of house numbers (i.e. 1201-1223) that have to be technically split into a list of single addresses and that produce a list of coordinates. This splitting step helps to determine the corresponding building footprint, which is in turn necessary to build the building level clusters.

[0063] (b) Raw combined data [Lat, Lon] 215113 -> OSM address: Matching the coordinate pair of raw combined data 215113 with addresses in the OSM database. This can also be done e.g. using GeoPy. However, this step is usually not useful: the main technical problem here is house number interpolation, which sometimes does not yield correct results. Moreover, if the query is close enough, the data processing returns a POI (point of interest) instead of an address.

[0064] (c) All obtained [Lat, Lon] -> OSM footprint: Matching the coordinates with OSM footprints. In this step, the system 1 determines whether any of the found locations belong to a building footprint. The query is constructed with the modified Overpass Python module. In the first step (I), all building footprints are retrieved within a certain grid cell using an Overpass query (all ways and relations with the tag "building"), e.g. within a 100m radius of the coordinates of raw combined data 215113. The retrieved geometries are processed with the GeoPandas and Shapely libraries (GeoPandas allows working with geospatial data in Python). GeoPandas extends the data types used by Pandas to allow spatial operations on geometrical types. The geometrical operations can be performed e.g. by Shapely. GeoPandas also computes the convex hull of each footprint according to Fiona for file access and Descartes and Matplotlib for plotting to simplify the shape. (II) The algorithm can then perform a search for polygon points for both the coordinate pair of raw combined data 215113 and the OSM coordinates in all obtained shapes. If the first search returns only one polygon, the match is labeled "exact". Otherwise, all matching returns are returned without the "exact" label. In case of no match, a buffer zone is added to all shapes and the search is repeated. (III) If no match is found, the buffer zone is increased and the search is repeated. To keep track of the uncertainty, the size of the buffer zone according to each matching return is added to the raw combined data 215113 (see Figure 19 steps I-III).

[0065] In comparison to the prior art systems, the system 1 provides a significantly improved technical treatment and results: a) For the example of forward geocoding of 4'017'430 records of unique raw combination data 215113 looking at the 4'017'430 samples, only 2'664'826 samples are provided as addresses, and only 1'947'876 addresses of the raw combination data 215113 can be geocoded. The obtained coordinates can be compared to the coordinates of the raw combination data 215113, for example by calculating the geodesic distance between two points. The results are assigned to 1 m bins and counted after 99% outlier filtering. The obtained histogram is visible in Figure 20 It can be noted that 85% of the distances lie in the range of 100 m, with two different peaks at 10 m and 20 m. These peaks can be related to the distribution of building sizes corresponding to each location: the OSM geocoding returns a location close to the street, while the coordinates of the raw combination data 215113 usually represent the centroid / point within the building. Therefore, the distance error will be smaller for smaller buildings, and larger for larger buildings. The obtained distances can be used as a confidence indicator. Figure 20 Two illustrative histograms are shown, where the upper part is a histogram of the distance error between the coordinate pairs of the raw combination data 215113 and the OSM coordinates in the range of 100 m. 85% of the geocoded results fall into this range. The lower histogram shows a histogram of the distance error for distances larger than 100 m, representing 15% of the results.

[0066] b) Regarding reverse geocoding, the following technical results can be exemplarily given: All entries of the raw combined data 215113 can be geocoded by the system 1 to OSM addresses, since each record contains a coordinate pair by definition. However, the obtained results have varying precision: 74% of the addresses can be resolved to house numbers, while only 5% match a RATOS entry, when available. This is because the system 1 relies on house number interpolation when not specified in the address. This additional street address information can be particularly useful for enrichment when no other source is available (70% of street names match the raw combined data 215113 street names).

[0067] Regarding the associated clustering process of the clustering module 2152 and the exposure data intelligence 215, one of the main technical challenges in the development of the system 1 is the technical clustering hierarchy and the logic behind it. The implementation of the system 1 can feature clustering at only one level, which has no defined properties other than their coordinates, IDs, and contained records. For the problem of clustering at a technical level, there are two different possible technical approaches and embodiment variants: one of them is implemented as a agglomerative clustering (see Figure 21 ), which is a bottom-up approach. The other applied process is called divisive clustering and follows a top-down approach (see Figure 21 ). Figure 22 The original purpose of clustering is shown: deduplication of the raw combined data 215113 records 21511,..., 2151i.

[0068] An applied "bottom-up agglomerative clustering" approach is proposed herein, which is technically based on nearest-neighbor clustering and fuzzy street address matching (Levenshtein distance) of the single raw combined data 215113 records 21511,..., 2151i currently at the highest level of granularity, thus referred to as "bottom-up approach" herein. The main advantage of this technical structure is that it can handle generic / unnamed cluster levels, however only when the respective distance function is properly designed: when operating on non-numerical and non-Euclidean spaces, this can become a technical challenge (e.g. for occupancy description spaces, it is difficult to come up with a meaningful distance metric). On the other hand, if the cluster levels are explicitly named (as in Figure 23 ), then the database records 21511,..., 2151i must provide the respective flag, and in the opposite case, a way must be provided to determine the closest cluster node in a meaningful way. However, the main disadvantage is that the geometry of the cluster is not taken into account, so that it is not possible to bind addresses to a specific building, but only to a house number. However, multiple different house numbers or even multiple street addresses can belong to the same building, which would lead to different clusters. Finally, the system 1 must be implemented to handle records 21511,..., 2151i without assigned street addresses but only [Lat, Lon] coordinates, and to include them into the hierarchy (see Figure 23 ). The applied "bottom-up divisive clustering" approach proposed herein can be visualized for example as Figure 24 in the illustration. The main difference compared to the previous processing structure (discussed above) is that this approach technically takes the geometry of the cluster into account and not only the semantics. In this approach, the granularity increases with the addition of each cluster node (before adding a cluster, its parent must be known), so that it is similar to a "top-down" approach. At the root level, there are place clusters, neighbor clusters or block clusters formed by road intersections. The next level of clusters is formed by single buildings inside the root clusters. At the lowest level, there are single risk / insurance items with defined [Lat, Lon] and address, which can basically be seen as de-duplicated raw combined data 215113 records 21511,..., 2151i. Figure 24 in the illustration also shows examples of meaningful cluster attributes at each level. For example, it can be beneficial to perform intermediate clustering at the root cluster and building cluster level (technically, this additionally speeds up clustering when the database becomes larger).a) Campus / Place / Block level: The technical key assumption of the system 1 is that campuses / places / blocks can be extracted from road intersections (see Figure 25). The applied techniques should be applicable to any location with roads. As an example variant, they can be extracted from OSM as multipolygon lines (by defining which road types and tags to look for), but technically also derived from other data sources (e.g. satellite images). Subsequently, the obtained set of lines can be polygonized, for example. Technically, this results in a set of polygons, which define the root level clusters, as Figure 26 shown in

[0069] b) Building level: Building footprints (see Figure 27 ) can be implemented similar to the streets of system 1 : they can be extracted from available OSM or other data providers, or even derived internally from satellite images and measurements. The advantage of OSM is that it can be used as a source for combined data enrichment, from which metadata tags and keys of interest can be captured (i.e. for building keys, we can find their type / value, similar to industry key - industry type), as Figure 28 shown in

[0070] c) Insurance item / risk level: At this level, the deduplicated raw combined data 215113 records 21511,..., 2151i are stored, with the special entry containing all IDs of the duplicates. For system 1, it is not necessary to store all metadata of the duplicates in the cluster database, as they can be looked up in the raw combined data 215113 with the IDs. Figure 29 The possible split of raw combined data 215113 into building and low-level risk attributes is shown. When new risks need to be added in the scheme or lookups / aggregations are performed at a specific level, Figure 29 the hierarchy explained in

[0071] As an embodiment variant, the two technical processing approaches can be combined in one in the system 1 as follows: first, for deduplication of the original combined data 2151 13 records 2151 1,..., 2151 i (at the lowest level) and for the case when a record cannot be assigned to a building (or other level) node, the fuzzy matching logic of the first approach can be used, thus requiring the creation of unnamed cluster levels that can be handled by the distance function developed for the agglomerative clustering. Second, the cluster geometry can be provided according to the partitioning approach. It can then be decided how to define and implement the root level clusters: either keep them as streets (in the form of buffer zones), however this automatically creates duplicates (for buildings that border multiple streets); or use polygons created by road intersections, which can also be used for efficient indexing. Thus, as an embodiment variant, a hybrid approach can be implemented as long as agreement is reached on the main intermediate cluster levels and the root level, and it is worth trying.

[0072] The use and access of the exposure database 2151 can be made more user friendly by querying a database accessible on a suitable user interface, such as a Web application, which enables the user to find clusters by address and coordinates and browse the corresponding properties with the help of a location intelligence engine 2156 (see Figure 30 ). Such a location intelligence engine 2156 Web application can be implemented by using the exposure database 2151 API, which returns, for example, a list of all matches in the exposure database 2151 and the best 10 matching clusters. The current implementation of the API has limited functionality, as the structure in the database is not yet sufficient. For this, the development of the backend (clustering algorithm) should be prioritized.

[0073] As an embodiment variant, the exposure database 2151 can be implemented to comprise invariant cluster IDs. I.e. creating a cluster scheme means defining unique cluster IDs, which for obvious reasons (adding new clusters and lookups) must also be invariant for large databases such as the exposure database 2151. It is technically important that the exposure database 2151 as a spatial database allows for the most efficient lookup structure: native points in polygon searches are completely infeasible for a given number of records clustered. This problem can be solved by the exposure database 2151 by the solution presented below, allowing for a more user-friendly, meaningful and efficient implementation of the state of the art system. The technical approach of this solution is based on using a proper hash code. This allows encoding locations into a form that is easier to use than showing coordinates in the usual form of Lat-Lon. For this, for example, Open Location Codes (OLC), also known as Google Plus Codes, can be used. They are designed to be used like a street address and can be implemented where there is no formal system to identify buildings, such as street names, house numbers, and postal codes. Open Location Codes can be derived, for example, from a latitude coordinate and a longitude coordinate, so they are already there. They are similar in length to a phone number, e.g. 849VCWC8+R9, but when combined with a place (CWC8+R9, Mountain View), they can usually be shortened to just four or six digits. Locations close to each other have similar codes. They can be encoded or decoded offline. The character set avoids characters that look similar to reduce confusion and errors. As an embodiment variant, similar approaches like GeoHash, MapCode, what3words, etc. can also be used. However, they all have the following disadvantages: (i) locations at the border (close to t.e.o.) have different prefixes, (ii) grid cutting through buildings, and (iii) the encoding geometry produces long lists, prefixes are not reusable. Therefore, as a preferred embodiment variant, the system 1 comprises a geo-hashing algorithm that can be applied to both single points and polygons. This scheme is implemented in a way that also allows determining whether a point belongs to a polygon by just looking at the code.

[0074] Finally, it should be noted that all prior art systems lack the functionality of adaptive grids, which technically avoids cuts through the clustering geometry. As an embodiment variant, the system 1 uses polygonal roads as grids. Roads naturally define a grid and do not cut through buildings. Moreover, their intersections already define place-level / block-level clusters. In other words, they create meaningful boundaries for the clusters. The system 1 allows indexing such cells / clusters by, for example, computing the centroid and simply encoding them with a short OLC (so that it is still distinguishable from others).

[0075] For positions inside a cell, the reference frame can be changed, for example, and the previously computed cell centroid can be used as the origin of a new x-y axis / geographical reference system (GRS) (the edge precisely defined by the OLC cell). Such a cell can be encoded with one of the 20 characters to obtain 5m precision on a 100m range. Thus, a single point / sub-cell can be defined, for example, as shown in Figure 32a while an area can be defined by adding multiple sub-cells together, as shown in Figure 32b Figure 31 An example of such an encoding scheme is shown. Each index corresponds to a character at the respective index position in the encoding alphabet, for example: (i) negative indices: 23456789CF, (ii) positive indices: GHJMPQRVX. In practice, this grid level can be as large as 1000m in both directions, which means that, for example, the method requires 200+ characters, lower precision, or longer codes. The main advantage of this embodiment variant is that it allows very efficient lookups, reduced to simple string searches / comparisons. The only prerequisites for this technical approach are: (i) knowledge of the cell centroid or [Lat, Lon] or OLC, which can be found / learned, for example, by applying ML techniques; (ii) knowledge of the encoding alphabet and scheme in the new GRS. The above scheme is only an exemplary implementation. There are other ways to encode a geometry, especially large ones consisting of many sub-cells, so that the resulting code of the above embodiment variant is long.

[0076] ​The present invention has in particular the advantage that it facilitates the creation of a rich, clean and structured representation of large raw portfolio data 215113: the system 1 allows to produce unique coverage-aware building clusters, as well as block / plot level clusters with invariant and modular cluster IDs. This allows to build a unique database that lifts automatic data insights and processing to a new level and broadens the horizon of data analysis as a large amount of previously unaltered raw data becomes available. The proposed system 1 can be used, for example, to improve internal portfolio data monitoring and clustering. It allows to cluster and identify the countless unique risks that occur in large databases such as the exposure database 2151 and to perform and efficiently aggregate and track risk attributes. Moreover, the system 1 can be easily applied to different lookup services, for example for underwriting / NatCat purposes, and also to end users in the context of, for example, emerging smart home applications. The system 1 and the exposure database 2151 allow to provide a large customer feedback and asset database that can be used as an enrichment source for customer portfolios, but also for other fields. With respect to current technology Nat Cat modeling and underwriting, the system 1 is able to: (i) identify buildings by their coordinates or unique IDs; (ii) query for risk and attributes, e.g. occupancy, including information about the content of buildings and businesses; (iii) group buildings to locations (campuses etc.); and (iv) track the evolution of attributes over time (construction and renovation years).

[0077] The system in particular provides (i) a new bulk geocoding solution, (ii) a geometry-aware clustering method, (iii) an invariant location-aware indexing method for each asset entered as raw portfolio data 215113, and (iv) a more user-friendly solution for querying and visualizing the large database as the exposure database 2151. Moreover, the system 1 has the advantage that it can be easily integrated. Integrating the system 1 as a service into other applications or customer tools / software not only significantly improves the user experience and risk assessment, but also gives new perspectives in terms of time and possible portfolio evolution at different aggregation levels.

[0078] Indicator simulation engine 10

[0079] As described above, the automated risk transfer configurator and risk transfer portfolio management platform (or system) 1 allows for the rapid assembly, launch and configuration of highly customized subordinated risk transfer structures. As an embodiment, the digital platform includes as an integrated part an indicator simulation engine 10. By means of the simulation engine 10, the measure and / or structural mix characteristics 141 of the underlying rate 103 of a risk transfer portfolio or basket 14 including the captured risk exposure units 102 are varied until a desired degree of change in the measure and / or structural mix characteristics 141 of the underlying rate 103 is reached. The indicator simulation engine 10 for the automated prediction of prospective and retrospective impact measures 101 is based on a time-dependent series of measured risk event measurement parameters 111 of the occurrence of physical impact risk events 11. The occurrence of physical impact risk events 11 is measured based on predetermined threshold values of the risk event measurement parameters 111, wherein the impact of physical impact risk events 11 on a specific physical or intangible real-world asset or living subject 12 is measured based on impact parameters 112 associated with the specific asset or subject 12.

[0080] The characteristic parameters 121 of the structured assets / subjects of the physical assets or subjects 12 are captured at least partially by means of a parameter-driven rule-based underwriting process 3 as an automated underwriting process, which dynamically captures the characteristic parameter values and maps these values to the structured characteristic parameters 121. A plurality of risk transfers 13 associated with the occurrence of one or more predetermined physical impact risk events 11 impacting the physical assets or subjects 12 is captured by the risk exposure units 102 and transferred by means of the captured risk exposure units 102 to the risk transfer portfolio or basket 14 holding the risk transfers 13. The structural mix characteristics 141 of the risk transfer portfolio or basket 14 are given by the type 132 of risk measured and captured with the associated risk exposure units 102 and the number 142 of allocated risk transfers.

[0081] A computer-based automatic risk transfer configurator and risk transfer portfolio management platform enables an automated binding of risk transfers between a user and the automatic risk transfer configurator, in particular acting as an automatic trading platform. The automatic risk transfer configurator can be operated, for example, by a service provider as an integrated part of a cloud-based service, in particular as a software-as-a-service on a cloud implementation. The system 1 is connected to various client terminals of users via a data transmission network 4, such as a telecommunication network and / or the global backbone network Internet. The data transmission network 4 can comprise, for example, a landline network and / or a mobile network and / or a satellite-based network. The data transmission network 4 can comprise, for example, a public switched telephone network, an ISDN (Integrated Services Digital Network) network or, preferably, the Internet or an intranet. Mobile networks can comprise, for example, a GSM network (Global System for Mobile Communications), a UMTS network (Universal Mobile Telephone System) or another network (for example, a satellite-based mobile network) or a WLAN (Wireless Local Area Network). User clients or terminals can access the system 1. The clients or terminals can be implemented, for example, as a PC (Personal Computer) 51, a mobile notebook or laptop computer 52, a mobile phone or PDA computer (Personal Digital Assistant) 53. The system 1 comprises a communication module 15 with a suitable network interface 151 for communication with the user clients, i.e. for data exchange. The communication module 15 is adapted, for example, to establish a virtual private network (VPN) with the user clients via the data transmission network 4 in each case and to communicate with the user clients via the virtual private network.

[0082] As shown in Figure 2 For data capture, the system 1 comprises suitable technical data capture means 16, in particular a rules database 161 and a plurality of processing modules, namely a control module 162, a verification means 163, an evaluation means 164, a transfer process module 165 and a user interface module 166. The transfer process module 165 comprises automatic transfer processes and semi-automatic transfer processes. The data capture means 16 can be constructed, for example, at least partially as programmed software modules or software portions on a computer program product.

[0083] The user interface module 166 may, for example, comprise program code for generating a user interface 1661 to the system 1, which can be operated by a user via the data transmission network 4 by means of a user client. The user interface is provided, for example, via a so-called browser program or as an API (application programming interface). The person skilled in the art will understand that the user interface 1661 can also be configured as a GUI (graphical user interface) in a client-server architecture. The user interface module 166 comprises a plurality of data input modules 1662. The data input modules comprise a data input field in each case, which is in particular for inputting data relating to the assets or objects of the risk transfer. Depending on the implementation of the user interface 1661, the data input modules 1662 comprise in each case one or more displayable windows or GUI images (“screens”) or scrollable forms. The data input modules are preferably assigned to the various paths of the workflow. The user interface 1661 can also be provided with a speech recognition module for data input.

[0084] The rule database 161 comprises information on data rules and risk transfer rules. In each case, the data rules 1611 and the risk transfer rules 1612 comprise one or more rule parameters 16111 / 16121 and rule logic 16112 / 16122. In the rule database 161, at least the rule parameters are stored, but preferably also the rule logic. The rule logic may, for example, be stored as process code, which can be executed on the system 1, for example as so-called applets in Java. For the risk transfer rules, the rule logic 16122 may, for example, comprise at least one or more supervisory conditions or other mandatory boundary conditions. The supervisory conditions may, for example, relate to data values of data input fields and different rule parameters. Furthermore, examples of supervisory actions to be carried out in accordance with an evaluation result determined on the basis of the supervisory conditions can be taken into account. For example, supervisory actions that can be specified can relate to the activation of different data input modules 1662 and to the activation of an automatic risk transfer process or a semi-automatic contract negotiation process. The rule logic 16112 / 16122 stored in the rule database 161 can comprise said supervisory conditions. In various variants of the embodiment, the supervisory actions can be permanently coded as part of the control module 162 or stored in the rule database 161 as part of the rule logic 16112 / 16122.

[0085] The data rules 1611 and the risk transfer rules 1612 are in each case assigned to one or more data input fields of the data input module 1662. The data rules 1611 are used by the validation means 163 to trigger and ensure the quality of the data input. The data rules 1611 technically specify the correct syntax and format, define prescribed value ranges, adjust plausibility and relationships between data values of multiple data input fields, for example the first data item must precede the second data item, and specify which data must be forced to be entered. The data rules 1611 are also used to check and ensure that the entered data values fit into a defined mathematical model or mathematical formula. The risk transfer rules 1612 are each used by the evaluation means 164 and the control module 162 to control the workflow process of the branch on the basis of the data input, to select various flow paths and to activate assigned data input modules and / or risk transfer processes. The risk transfer rules provide a multi-level nested selection process of data control. For example, if the data value input or the sum of a plurality of data value inputs exceeds a defined threshold value, or if a specific contract object class or group is specified on the basis of the data input, the user can be requested to enter further additional data values by activating the data input module 1662. As long as the evaluation means 164 consider that the conditions set by the risk transfer rules 1612 are met (positive evaluation result), the control module 162 proceeds along the path with the least data input. However, if the evaluation means 164 consider that the conditions set by the risk transfer rules 1612 are not met (negative evaluation result), the control module 162 proceeds along the path with additional data input and activates the corresponding additional data input module. The data rules 1611 and / or the risk transfer rules 1612 are assigned to rule sets which are assigned different setting identification data. The setting identification data can for example include geographical data, user identification data and / or service identification data. The setting identification data enable the selection and activation of the data rules 1611 and / or the risk transfer rules 1612 depending on the data value input.

[0086] The simulation engine 10 applies a measure of a basic premium rate 103 to a risk exposure unit 102 associated with a specific type 132 of risk transfer 13 on the basis of the risk event measure parameter 111 of the risk transfer 13 and the structured asset / object characteristic parameters 121 of the physical asset or object 12 determined by means of the simulation engine 10. The basic premium rate 103 provides a cost measure of the resources required to cover the risk associated with the specific risk transfer 13. Multiplying this basic premium rate by the number 131 of risk exposure units 102 of the specific risk transfer 13 generates the premium of the risk transfer 13.

[0087] The simulation engine 10 dynamically provides the prospective and retrospective impact measures 101 based on changes in the measure and / or structure mix characteristics 141 of the underlying base rates 103 of the risk transfer portfolio or basket 14 including the captured risk exposure units 102. The prospective and retrospective impact measures 101 include at least a total premium amount 1011 associated with the portfolio of risk transfers and / or a net premium amount 1012 given by the total premium amount 1011 less a premium associated with a secondary risk transfer allocated to a portion of the transferred risk exposure units of the portfolio, and / or a total expected loss 1013 measure and / or a CM1 1014 measure.

[0088] As mentioned above, the provision of the basic rate, the parameter of the physical correlation of the product mix to the measurement parameters of the GWP, NWP, expected loss and CM1 is based on the measurement and balancing of the level of the parental resource pool. Technically, for the measurement, the risk pool level measures, i.e. the balancing of the payment transfer of the pool to the assets or the amount of capital measure that is required to make it the default free parameter value that is related to its measured risk exposure. Like the automatic risk transfer system 1 in the risk transfer portfolio of the first level risk transfer system assigned here, each risk transfer to the second level insurance (reinsurance) system is associated with a parental guarantee measure. If the second level risk transfer system cannot pay for its own claims, the first level risk transfer system can utilize the available funds of the reinsurance system. When the insurance system fills out the policy with defined risk transfer parameters (which technically define the interval and range of the risk transfer), it receives the premium. Part of this policy can be considered as a loss component. When a specific risk event occurs with an accompanying loss, the insurance system has three possible ways to cover these losses. The first is the loss component of the risk transfer policy itself. In many cases, this will not be enough to cover and balance the loss. The second source is the unused loss component of other risk transfer policies. In most cases, these two sources will be sufficient to pay for the loss. Over time, these two sources will be insufficient, and the insurance system must look for a third source, i.e. the excess, to cover the measured loss associated with the occurrence of the risk event. In the third case, the insurance system can cover the guaranteed value by covering it with the second level risk transfer system. In order to technically allow the implementation and capture of the relationship, a person skilled in the art can, for example, based on the following technical assumptions and boundary conditions of the system 1 : (A) the capital of the first level risk transfer system is a shared asset, all risk transfer policies in the portfolio potentially have the right to access all shared and accumulated capital simultaneously; (B) the effect of underwriting risk transfer policies and implementing appropriate risk transfer parameters on the first or second level risk transfer system is (i) to occupy some of the limited underwriting capacity of some of the systems (as determined by the required capital measure and forecasts) over a period of time, and (ii) the risk transfer system extends the guarantee to the contract allocation system or the risk exposure unit to meet the legal claim request for the measured loss. These effects represent different types of use of the accumulated capital and monetary resources of the risk transfer system, respectively; (C) each different type of capital use will result in a unique charge: a capacity occupancy cost measure and a capital call cost measure; (D) in all possible scenarios of risk transfer policy closing, the expected parameter values of these two cost parameters are defined in this document as capital use cost parameters, and will be considered as a cost measure in the risk transfer policy pricing parameter forecasts.Thus, the contribution of the risk transfer policy to the risk transfer system is not a return on capital, like the ratio of expected profit and allocated capital, but a profit minus a capital usage cost parameter; (D) Subsequently, the preferred technical decision indicator becomes the added economic value, which is a means of adjusting the risk return by subtracting the opportunity cost of capital. In summary, technically, the actual capital pool level measure of risk transfer creates underwriting capacity, and the underwriting (i.e., risk transfer) activity (past or present) depletes (consumes) the underwriting capacity.

[0089] The temporary reduction in the generation of required capital (i.e., accumulated resources) by either the transfer of premiums or the parameter values of the retention system temporarily reduces the amount of capacity measured for other underwriting. Since it is temporary, it is analogous to a capacity occupancy measure for the risk transfer system, a non-consumptive use of shared assets. Capacity consumption occurs when the retention must increase beyond the forecasted level measure. This can for example technically involve a transfer of funds from the capital account measure to the retention account measure. The entire surplus measure is available to each policy to cover losses beyond the accumulated loss component. Even if the expected and forecasted loss components are equal, some risk transfer policies are more likely than others to generate such a need. Thus, for risk transfer policies with similar expected losses, the system can be implemented to automatically expect the policies with the greater variability of likely outcomes to require more contribution from the surplus to cover losses by resource transfer. For example, the risk transfer system can be implemented to request a charge parameter for granting access to the surplus resources. This charge parameter can for example depend not only on the likelihood of possibly needing the surplus, but also on the order of magnitude of such a surplus call or request. Thus, the two different technical impacts of the risk transfer underwriting risk transfer portfolios on the risk transfer system are collectively: (i) a specific occupancy of underwriting capacity over a period of time, and (ii) a possible depletion of the capital measure. The use of such a "dual-polar" capital measure can for example provide a basis for the technical structure of the system. This dual form of monetary payment transfer for the technical dual-use nature can for example be adapted to the unique technical characteristic of the risk transfer system.

[0090] It is important for understanding the technical challenges of automating a risk transfer system that setting the appropriate boundary structures and frameworks that allow operating the system on a technical basis is already challenging for the technicians. For example, under the technical boundary assumption of a perfect free market environment, an entity offering a product for sale should try to set the price at which the entity is willing to sell the product without impairing its operation and the consumer is still willing to buy the product. Determining the supplier-side price to be charged for any given product is conceptually straightforward. The simplest model focuses on the idea that the applied pricing should reflect the costs associated with the product and incorporate an acceptable profit margin. For many risk transfer-unrelated products and services, the production costs are known before the product is transferred to the buyer, i.e. sold. Thus, the initial price can be set by the system such that the desired profit per unit of product will be realized without impairing the operation of the system. Risk transfer differs from such products because it relies on a forecasted future technical target that does something if certain physical events occur and will be measured during a specified time period. For example, a risk transfer can be associated with a future target to guarantee the reconstruction of a house in case it burns down or to guarantee the medical treatment of a worker injured at work. Unlike a can of soup, a pair of shoes or a car, the final and actually measured cost level of a risk transfer policy is unknown at the time of sale. This places the classic, technically unimportant target of product and monetary transfer into a technically different, predictive and difficult context and introduces additional complexity into the process of setting the pricing and operational parameters for a risk transfer system. Thus, the expected loss measure is not time-invariant but needs to be readjusted by the risk transfer system when environmental measurement parameters or other external circumstances change. Sometimes, both the measured default probability and the measured default loss increase, which gives two reasons for an increase in the expected loss. For example, the default value of a certain class of homeowners was only 5% over a period of 20 years. However, when a system crisis occurs and home values fall by 30% for a long time, the default behavior of the same class of borrowers changes. Instead of the default 5%, say, the default 10% is no longer the norm, mainly due to a catastrophic increase in the LGD (loss given default). To accommodate this type of situation, a much larger expected loss needs to be forecasted. This is a subject that is subject to considerable technical challenges, as it has a large impact on the operation of an automated risk transfer system for mitigating system risk measures. Thus, for a possible technical implementation of the expected loss measure, the parameter can be implemented as a measure of the sum of all possible loss values, each loss value multiplied by the probability of the occurrence of that loss. Technically, three factors can be assumed to be related to the forecasted expected loss value: (i) the probability of default (PD), (ii) the exposure at default (EAD), (iii) the loss given default (LGD), where the loss given default is set as the size of the possible loss on the exposure / exposure at default.

[0091] Reference list 1 Automated risk transfer configurator and risk transfer portfolio management platform (or system)

[0092] 10 Simulation engine

[0093] 101 Prospective and retrospective impact measures

[0094] 1011 Gross written premium (GWP)

[0095] 1012 Net written premium (NWP)

[0096] 1013 Total expected losses

[0097] 1014 CM1

[0098] 102 Risk exposure units

[0099] 103 Base rates

[0100] 104 Premium (amount of resource to be allocated for risk transfer)

[0101] 11 Physical impact risk events

[0102] 111 Risk event measurement parameters

[0103] 112 Impact parameters on specific assets or perils

[0104] 12 Physical or intangible real-world assets or living perils 121 Structured asset / peril characteristic parameters

[0105] 13 Risk transfers associated with occurrence of a predetermined risk event impacting a physical asset or peril

[0106] 131 Number of risk exposure units

[0107] 132 Type of risk associated with risk transfer

[0108] 14 Risk transfer portfolio or basket

[0109] 141 Structural mix characteristics

[0110] 142 Number of risk transfers

[0111] 15 Communication module

[0112] 151 Network interface

[0113] 16 Data capture device

[0114] 161 Rules database

[0115] 1611 Data rules

[0116] 16111 Rule Parameters

[0117] 16112 Rule Logic

[0118] 1612 Risk Transfer Rules

[0119] 16121 Rule Parameters

[0120] 16122 Rule Logic

[0121] 162 Control Module

[0122] 163 Verification Device

[0123] 164 Evaluation Device

[0124] 165 Transfer Process Module

[0125] 166 User Interface Module

[0126] 1661 User Interface

[0127] 1662 Data Input Module 2: Automated End-to-End Process

[0128] 21. Automated underwriting using rule-based branching processes

[0129] 211 Create and Submit

[0130] 212 Receiving and Binding Quotes

[0131] 213 Modification and Update of Commitments

[0132] 214 Product Configurator

[0133] 2141 Coverage Area Parameters

[0134] 2142 Business Scope Parameters

[0135] 2143 Risk Transfer Type Parameter

[0136] 2144 Risk Information Parameters

[0137] 215 Intelligent processing of machine-based exposure data

[0138] 2151 Exposure Database

[0139] Data records 21511,…,2151i

[0140] Attribute parameters of asset / target 12 (215111) and location parameters (215112)

[0141] 2151121 latitude coordinates

[0142] 2151122 longitude coordinates

[0143] 215113 Original combination data

[0144] 2152 Clustering Module

[0145] 21521 Automatic address matching

[0146] 21522 grid

[0147] 215221 grid cells

[0148] 215222 grid cell scale

[0149] 215223 Adaptive cell size and / or shape 215224 Local residential / building density

[0150] 2153EDI (Intelligent Exposure Data Processing) Engine

[0151] 21531 Search service access

[0152] 21532 Forward-looking modeling module

[0153] 2154 User Data Interface

[0154] 2155 Cross-level analysis module

[0155] 21551 Recognition

[0156] 21552 Analysis

[0157] 21553 Visualization

[0158] 2156 Location Intelligent Processing Engine

[0159] 216 Geocoding Processing Module (Map Server)

[0160] 22 Technical Accounting Process

[0161] 221. Booking Insurance Premium

[0162] 222 Recommendations for New Claims

[0163] 223 Booking and Update Claims

[0164] 224. Adjusted premium

[0165] 225 Submit account report

[0166] 23 Financial Accounting Process

[0167] 231 Recommendation and / or Requirement of Payment

[0168] 232 Seamless Pairing

[0169] 233 Set-up account 3 rules-based underwriting process

[0170] 31 Standard

[0171] 311 Automation

[0172] 3111 Trigger parameters that meet the trigger rule

[0173] 312 Semi-automation

[0174] 3121 Several parameters that do not meet the trigger rule

[0175] 32 Non-standard

[0176] 321 Underwriting process does not include automated pricing

[0177] 4 Data transmission network

[0178] 5 Customer or access terminal

[0179] 51 PC (Personal Computer)

[0180] 52 Mobile notebook or laptop computer

[0181] 53 Mobile phone or PDA computer (Personal Digital Assistant)

[0182] 54 GPS module

[0183] 55 Optical sensor and / or camera 6 Combined analysis framework

[0184] 61 Dynamic representation

[0185] 7 Customer rate offer module.

Claims

1. A digital optical automation system comprising a simulation engine for automatically predicting forward and backward impact measures based on the values ​​of event parameters for measuring the occurrence of a time-related series of physical impact events, said physical impact events including at least earthquake events, storm events, and flood events, wherein, The occurrence of a physical impact event is measured based on a predetermined threshold of an event parameter, wherein the impact of the physical impact event on a specific physical or real-world asset is measured based on an impact parameter associated with the asset, characterized in that: The structured characteristic parameters of physical assets are captured, at least in part, by means of a parameter-driven, rule-based branching process. This branching process dynamically captures characteristic parameter values ​​and maps these values ​​to structured characteristic parameters, which at least capture geographic and structural physical characteristics and attributes, as well as flood physical characteristics and attributes, storm physical characteristics and attributes, and earthquake physical characteristics and attributes. Multiple risk transfers associated with the occurrence of one or more predetermined physical impact events affecting the physical asset are captured via risk exposure units and transferred to a combination or basket holding the risk transfers by means of the captured risk exposure units. The structural mixing characteristics of the combination or basket are given by the type of risk measured and captured using the associated risk exposure units and the number of risk transfers allocated. The digital optical automation system includes machine-based intelligent processing of exposure data to automatically identify specific risks of the physical asset based on its precise location. This machine-based intelligent processing of exposure data includes a user interface accessible via a smartphone to input location data of the physical asset through the smartphone's GPS module and / or optical sensor or camera. The physical asset can be scanned using data transmission from the GPS module and / or optical sensor or camera to the digital optical automation system via the smartphone, which is equipped with GPS and a camera. The machine-based intelligent processing of exposure data includes an exposure database comprising multiple data records holding attribute parameters of properties with assigned geographic location parameters, wherein attribute parameters are retrieved from the exposure database, the attribute parameters including at least (i) occupancy level, (ii) primary structural type, (iii) detailed structural type, and (iv) design year, and wherein the machine-based intelligent processing of exposure data includes providing an engine for exposure-based natural disaster modeling via a forward-looking modeling module, the forward-looking modeling module including a natural disaster risk modeling structure that generates loss distributions of physical impact events, including earthquakes, storms, and floods, relative to their geographic maximum exposure. The digital optical automation system includes a geocoding processing module for performing forward and reverse geocoding at different levels, said different levels including at least buildings and / or streets and / or regions and / or suburbs and / or counties and / or states, wherein the measured location data is matched with building coverage areas retrieved from a database within grid cells of the measured location data, and wherein an adaptive cell size and shape is used based on the measured local residential and / or building density, and wherein said adaptive cell size and shape uses polygonal roads as the grid without penetrating buildings, and the intersections of the grid are defined as location-level or block-level clusters. To match the measured location data, the digital optical automation system is configured to (i) retrieve all building coverage areas, including at least the geometry and geometry type, from the Overpass module within a grid cell of the measured location data with a defined radius, and generate the convex hull of each coverage area; (ii) perform polygon point matching on the measured location data and the geocoded coordinates of all obtained shapes; and (iii) if the first match does not return a polygon, no match is found, the defined radius is increased, and the matching is repeated. The simulation engine applies a basic premium rate measure to risk exposure units associated with a specific type of risk transfer, based on event parameters of the risk transfer and asset characteristic parameters of the physical asset determined by the simulation engine. The basic premium rate measure provides a cost metric for covering the resources required to cover the risk associated with the specific risk transfer, and the premium for the risk transfer is generated by multiplying the basic premium rate measure by the number of risk exposure units for the specific risk transfer. The simulation engine dynamically provides forward and backward impact measures based on changes in the basic rate measures and / or structural hybrid characteristics of the portfolio or basket, including captured risk exposure units. The forward and backward impact measures include at least a measure of the total premium associated with the portfolio or basket of risk transfer and / or a measure of the net premium given by the total premium minus the premium associated with the secondary risk transfer of the risk exposure units allocated to the portfolio or basket, and / or a measure of total expected loss.

2. The digital optical automation system according to claim 1, characterized in that, The simulation engine is implemented as an integrated part of a cloud-based application.

3. An automated risk transfer configurator for rapidly assembling, launching, and configuring highly customized secondary risk transfer structures, characterized in that, The automatic risk transfer configurator includes a simulation engine as claimed in any one of claims 1 or 2, wherein the base rate metric and / or structure blending characteristics of a combination or basket, including captured risk exposure units, are altered until a desired degree of alteration is achieved with respect to the base rate metric and / or structure blending characteristics.

4. The automatic risk transfer configurator for rapidly assembling, launching, and configuring highly customized secondary risk transfer structures according to claim 3, characterized in that, The desired level is determined by achieving a local optimum value for the change in the base rate metric and / or the structural hybrid characteristics.

5. The automatic risk transfer configurator for rapidly assembling, launching, and configuring highly customized secondary risk transfer structures according to claim 3 or 4, characterized in that, Changes to the values ​​of the basic rate metric and / or the structure hybridity characteristic are performed by the simulation engine based on interactive input values ​​from the user of the automatic risk transfer configurator.

6. The automatic risk transfer configurator for rapidly assembling, launching, and configuring highly customized secondary risk transfer structures according to claim 3 or 4, characterized in that, Changes to the values ​​of the basic rate metric and / or the structure hybridity characteristic are performed by the simulation engine based on the changed input values ​​generated by the automatic risk transfer configurator.

7. The automatic risk transfer configurator for rapidly assembling, launching, and configuring highly customized secondary risk transfer structures according to claim 3 or 4, characterized in that, Adjustments to portfolio or basket metrics are reviewed and audited interactively by the user to ensure compliance with management, risk, and safety requirements.

8. The automatic risk transfer configurator for rapidly assembling, launching, and configuring highly customized secondary risk transfer structures according to claim 3 or 4, characterized in that, The automatic risk transfer configurator is implemented as an integrated part of a cloud-based application.

9. A method for a simulation engine, said simulation engine automatically predicting forward and backward impact metrics based on the values ​​of measured event parameters of a time-dependent series of physical impact events, said physical impact events including at least earthquake events, storm events, and flood events, wherein, The occurrence of a physical impact event is measured based on a predetermined threshold of an event parameter, wherein the impact of the physical impact event on a specific physical or real-world asset is measured based on an impact characteristic parameter, characterized in that: The characteristics of physical assets are captured, at least in part, by means of parameter-driven branching procedures. These branching procedures dynamically capture characteristic parameter values ​​and dynamically map these values ​​to structured characteristic parameters, which at least capture geographic and structural physical characteristics and attributes, as well as flood physical characteristics and attributes, storm physical characteristics and attributes, and earthquake physical characteristics and attributes. Multiple risks associated with the occurrence of one or more predetermined physical impact events that may affect physical assets are captured through risk exposure units. These multiple risks are then transferred to a combination or basket of captured risk exposure units, wherein the structural hybridity of the combination or basket is given by the type of risk measured and captured, the amount of risk transferred, and the associated risk exposure units. Machine-based intelligent processing of exposure data is performed to automatically identify specific risks of the physical asset based on its precise location. This machine-based intelligent processing includes accessing a data interface via a smartphone to input the location data of the physical asset through the smartphone's GPS module and / or optical sensor or camera. The physical asset can be scanned using data transmission from the GPS module and / or optical sensor or camera to a digital optical automation system via a smartphone equipped with GPS and a camera. Machine-based intelligent processing of exposure data includes an exposure database comprising multiple data records holding attribute parameters of properties with assigned geographic location parameters, wherein attribute parameters are retrieved from the exposure database, the attribute parameters including at least (i) occupancy level, (ii) primary structure type, (iii) detailed structure type, and (iv) design year, wherein the machine-based intelligent processing of exposure data includes providing an engine for exposure-based natural disaster modeling via a forward-looking modeling module, the forward-looking modeling module including a natural disaster risk modeling structure that generates loss distributions of physical impact events, including earthquakes, storms, and floods, relative to their geographic maximum exposure. A geocoding processing module performs forward and reverse geocoding at different levels, said different levels including at least buildings and / or streets and / or regions and / or suburbs and / or counties and / or states, wherein the measured location data is matched with building coverage areas retrieved from a database within the grid cells of the measured location data, and wherein an adaptive cell size and shape is used based on the measured local residential and / or building density, and wherein said adaptive cell size and shape uses polygonal roads as the grid without penetrating buildings, and the intersections of the grid are defined as location-level or block-level clusters. Within a grid cell with a defined radius of the measured location data, retrieve all building coverage areas from the Overpass module, including at least the geometry and geometry type, and generate the convex hull for each coverage area; (ii) perform polygon point matching on the measured location data and the geocoded coordinates of all obtained shapes; and (iii) if the first match does not return a polygon, no match is found, increase the defined radius, and repeat the matching process. The simulation engine applies a base rate metric to risk exposure units associated with a specific type of risk transfer, based on selected event parameters of the risk transfer and selected characteristic parameters of the physical assets determined by the simulation engine. The base rate metric provides a cost measure of the resources required to associate with the specific risk transfer, and the premium is given by multiplying the base rate metric by the number of risk exposure units for the specific risk transfer, whereby the premium is the amount of resources to be allocated for the risk transfer. The simulation engine dynamically provides forward and backward impact measures based on changes in the basic rate measures and / or structural mixing characteristics of the portfolio or basket, including captured risk exposure units. The forward and backward impact measures include at least a measure of the total premium associated with the portfolio or basket of risk transfer and / or a measure of the net premium, including the total premium minus the premium associated with the secondary risk transfer of the portion of the risk exposure units allocated to the portfolio or basket, and / or a measure of total expected loss.

10. The method according to claim 9, characterized in that, The automatic risk transfer configurator uses a simulation engine to change the base rate metric and / or structure blending characteristics of a combination or basket, including captured risk exposure units, until a local optimum is reached regarding the change values ​​of the base rate metric and / or structure blending characteristics.

11. The method according to claim 9 or 10, characterized in that, Adjustments to portfolio or basket metrics are reviewed and audited interactively by the user to ensure compliance with management, risk, and safety requirements.

Images