Digital platform providing a closed b2b2c system through a modular domain components architecture forming a bounded context with interaction via microservices, and method thereof

Abstract

Proposed is a digital platform (1) providing automated risk transfers by processing risk related data by extracting risk-related parameter values and information regarding an object at risk, wherein the monitoring and / or assessment comprises probability measures for occurrences of life risk events and / or non-life risk events at least comprising natural hazard events (10) and / or accident related events (12, 14) and / or cyber risk events for providing risk measuring of risk exposures of the object at risk based on extracted risk-related parameter values associated with the object at risk. The digital platform (1) is based on a digital network environment (100) at least hosting an infrastructure domain (200), a risk assessment domain (300) and a risk transfer domain (400). The infrastructure domain (200) at least comprises an operating module (202), a database module (204), a networking module (206), and an input / output module (208). The risk assessment domain (300) at least comprises a monitoring and / or assessment module (302, 304). The risk transfer domain (400) at least a comprises a risk processing module (402, …, 418) for insurance management along a risk transfer supply chain (600). The modules of the infrastructure domain (200), the risk assessment domain (300) and / or the risk transfer domain (400) form a bonded context structure, which is based on a microservices architecture (500) providing the modules as decentralized independent microservice modules which are distributed in the digital network environment (100).

Description

[0001] Digital platform Providing a Closed B2B2C System Through a Modular Domain Components Architecture Forming a Bounded Context With Interaction Via Microservices, and Method Thereof

[0002] Field of the Invention

[0003] The present invention relates to a digital platform for platform users, such as complex business and customer networks, enabling integration of sensible, quantified data, data processing and handling as well as secure access to relevant information and / or evaluation, inter alia, using a web-based environment. Particularly, the invention relates to a digital platform for enabling digital risk transfer and facilitating automated collaboration between assessing businesses and between businesses and customers by cloud-based communication channels and enabling exchange and exploitation of risk data and information.

[0004] Background of the Invention

[0005] The digital transformation in the insurance sector is rapidly advancing across the full insurance value chain opening up new technological approaches and enabling data-driven decision making supported by digital network infrastructure. Effective data management techniques allow insurers to process and analyze large volumes of physical and customer data efficiently. Advanced analytics and machine learning algorithms are able to extract valuable insights from data collected through various devices connected to the network. These insights enable insurers to identify patterns, trends, and risk factors resulting for example in more precise risk assessment and pricing modelling. Data management platforms allow insurers to offer personalized services and engage with customers in new ways. For instance, insurers can give policyholders real-time feedback on customers' activities or provide customized risk management recommendations. A key driver of this digital development is capturing quantified physical data related to insurance risks, damage specifications or customer circumstances. Modern digital data acquisition captures such data by environmental monitoring and detection systems, collecting existing measuring values or identifying technical specifications of subjects at risk, while continuously advancing data analytics models which allow for precise, reliable and comparable risk assessment to make informed decisions and help underwriting agencies understand what products and services are successful. Digital insurance solutions are able to leverage network devices to monitor and mitigate risks proactively. For example, sensors can spot problems like water leaks, changes in temperature, or security breaches early on. They can help to reduce potential damage and insurance claims, saving money for both insurance companies and their customers. Digital data management can streamline the claims process; for example, real-time data from connected devices can automatically trigger claims notifications, initiate the assessment process, and expedite claims settlement.

[0006] All together a large number of stakeholders is involved in the risk assessment and transfer business. In addition to customers ordering individualized risk related products and insurance carriers providing customized contracts and tariffs, there are underwriting agents, independent insurance brokers, capital providers, risk advisors and others. Additionally, various independent service providers for gathering risk related technical information and data, and analyzing and processing risk related information and data are providing important input for defining quantified risk assessment and processing for insurance cases.

[0007] Digital platforms establish a collaboration ecosystem based on a shared set of technologies, components, services, architecture, and relationships that serve as a technical foundation used by these diverse sets of actors to converge and improve the technical risk analysis along the full value chain. Traditionally digital core risk management platforms are based on a self-contained monolithic architecture, wherein multiple components are combined into one large application. For example, components for authorization, presentation, business logic, data gathering, data access, data analysis, communication and application integration are all interconnected by the monolithic application structure. Nevertheless, additional functionalities can be implemented in the application for example by add-ons, which however may require the whole application to be compiled and tested. For example, US 10489798 Bl shows a digital platform for a digital insurance marketplace which is able to store different rules for qualifying and / or categorizing insurance leads based on at least one insurance characteristic. The platform provides insurance leads that were received from an insurance lead source to a requesting agent, determines a quality associated with and / or categorize each insurance lead based on one or more characteristics of the received insurance leads, presents the insurance leads to an insurance agent based on selected lead characteristics or lead tiers, and determines information associated with an actual quality of each insurance lead based upon feedback received from the agent and revise rules for qualifying or categorizing the insurance leads using the actual quality of the insurance leads. The application combines numerous processing and management options and connects various users.

[0008] While monolith systems provide a one stop shop for all core risk management business processes, rapidly evolving market forces and evolving technologies, have brought huge disruptions to insurers core insurance platforms that build the foundation for policy management, customer interaction and claims processing. These platforms are playing a catch-up game to meet today's insurer's needs of faster time-to-market for agile insurance products and services, embedded predictive analytics to take faster decisions, straight through processing for core business operations, integrated design and systems to enhance customer experience, and increased operational efficiencies. Modern risk management applications often are based on a cloud-supported modular structure built up from multiple modules that communicate with one another through application programming interfaces (APIs) . Each individual application module can be scaled, updated and deployed separately. Such advanced applications can exchange technical data and information with existing insurance platforms or may be implemented therein. Thus, it is a need to provide new technical approaches for the migration of monolith systems to a microservices architecture considering and optimizing migration effort and performance issues relevant in the migration to a modular monolith.

[0009] The technical need origins from the agility inherent to today's business which promotes and puts the technical requirements to the definition of usable system architectures where the business entities are decoupled into modules and / or services. There are advantages in having a rich domain model, where domain entities are tightly connected, because it fosters reuse. On the other hand, the split of the business logic into modules and its encapsulation through well-defined interfaces introduces a cost in terms of performance. The present invention allows to technically increase the impact of migrating a rich domain object into a modular architecture, both in terms of the development cost associated with the refactoring, and the performance cost associated with the execution.

[0010] For example, US10467702B1 discloses a peer-to-peer platform. The digital platform enables sharing of goods and services among insurance policyholders. A listing including a listing category for a good or service to be offered in the peer-to-peer marketplace can be received. An insurance policy quote to cover a rental transaction of the good or service offered in the listing can be generated, and both the listing and quote can be stored in a data repository. Finally, a search category can be received, and one or more listings can be determined to be pertinent based on the search category. The determined pertinent listings can be presented, and the rental transaction can be received. US 2014046723 Al shows another digital system which provides a web-based platform for distributing leads to a network of agents. The platform receives data indicative of user identification and user insurance coverage from a plurality of website users, identifies a subset of the plurality of website users that fail to purchase insurance, generates a database that stores the data received from the subset of website users, and generates a price for purchasing the data received from each of the subset of website users. The price is added to the respective website user's data in the database. The method includes transmitting a portion of the database including the price to a third party and receiving a request to purchase a first website user's data.

[0011] Although the digitization of the risk management sector is vastly progressing, the growing complexity of modern digital platforms by adding, connecting or integrating independent additional product or service applications based on technical data analysis need to be handled very carefully. The creation and deployment of such platforms as well as their maintenance and testing requires specialized expertise and knowledge. Additional technical security measures may be needed to guarantee cyber security for all stakeholders. The independent structure of the various modules involved in the operation of digital platform systems and integration of physical data sources renders the application management and performance monitoring of such systems difficult and time consuming. Another technical issue threated by the present invention comes from the fact that information systems are moving into the cloud. The new requirements enforced by cloud standards are high availability, high scalability, and a reduced mean time to recovery. Due to these new technical requirements, information system architecture styles are evolving. The present invention provides a microservice architecture as a highly modular cloud information system. One of the big unsolved technical problems, associated with microservices concerns how to choose the granularity of a microservice.

[0012] The present invention allows to provide an optimal point of granularity for microservices based on coupling and cohesion values. Two embodiment variants are generated that apply domain-driven architecture in using microservices. Both embodiment variants are provided to generate granular microservices. The coupling and cohesion values of the original examples can be compared to prior art systems of more and less granular microservices, thus providing a technical ability to benchmark the performance of the different systems. It can be observed that domain-driven architecture of the present inventive system is delivering improved end results for modular microservices.

[0013] Summary of the Invention

[0014] It is an object of the present invention to provide a digital platform for data- and process-driven risk transfer management and program / product development, in particular for integrating technical solutions focusing on diverse requirements of various interest groups for establishing a user-friendly risk transfer and management system. The digital platform shall allow for capturing, measuring, and quantifying physical real-world assets and objects based on physical risk measuring parameter values and data, allow for generating appropriate risk assessment and risk accumulation measures, and shall be able to connect various data related programs / products of a risk transfer supply chain. The present invention shall provide a new technology for automated digital processing of risk transfer products across two or more individual users of the digital platform, for exchange of data, executables, requests, instructions, and other kind of electronic signal exchange between various levels and processing steps, and for facilitating risk transfer product development, risk assessment, and risk transfer policy and claims management. Particularly, the digital platform shall allow to bring together different classes / groups of users, such as carriers, brokers, underwriters, policy customers, program and project engineers, third party service providers and producers involved in risk transfer products for smooth and transparent interaction and for sharing data / information, enhancing collaboration of participants, supporting development and innovation of new programs, products and services, and improving customer services. The digital platform may also be realized to allow to provide cross-user programs, projects or resources on a networking basis while operating under clear governance conditions that protect program developments, technology secrets, intellectual property and data ownership. The digital platform shall be easily scalable and adaptable for expanding data / information processing needs and differing user requirements, and easily accessible for processing of data / information related to measuring parameters / factors, such as measuring values and risk factors. The digital platform shall be enabled for standardized processing of data and measuring parameters from multiple heterogeneous data sources, such as network measuring devices, multiple data storage means and pre-processing entities. It shall support controlled access and individualization for diverse participants and providers in the risk transfer chain, particularly for risk identification, risk assessment, policy specification, policy issuance and claims handling by automated, electronic and cross-user data / information management and controlled knowledge exchange.

[0015] According to the present invention, these objects are achieved, particularly, by a digital platform with the features of the independent claim. In addition, further advantageous and alternative embodiments of the digital platform can be derived from the dependent claims and the related descriptions.

[0016] The digital platform according to the present invention provides automated risk transfers by processing risk related data by extracting risk-related parameter values and information regarding an object at risk. The automated risk transfers are based on monitoring and / or assessment of probability measures for occurrences of life risk events and / or non-life risk events at least comprising natural hazard events (10) and / or accident-related events (12, 14) and / or cyber risk events for providing risk measuring of risk exposures of the object at risk based on the extracted risk-related parameter values associated with the object at risk. The digital platform processes risk related data and / or information based on monitoring and / or assessment for example of extracted risk related physical parameters captured by measuring and / or sensory devices. The measuring and / or sensory devices provide risk parameter measuring and information regarding the object at risk. The monitoring and / or assessment comprises measuring probability measures for occurrences of the life risk events and / or non-life risk events for providing risk measuring of risk exposures of the object at risk based for example on location and condition measurements associated with the object at risk. For example, the monitoring and / or assessment measures probability measures for the occurrence of flood, earthquake and / or hurricane events at the location of the object at risk, or measures probability measures for the occurrence of an accident due to speeding, tiredness of the driver, vehicle condition, etc. Advantageously, the measuring and / or sensory devices may automatically monitor and / or assess the risk related physical parameters and provide the data and / or information for the risk transfer system.

[0017] The digital platform is based on a digital network environment at least hosting an infrastructure domain, a risk assessment domain and a risk transfer domain. The infrastructure domain at least comprises an operating module, a database module, a networking module, and an input / output module. The infrastructure domain provides an electronic infrastructure at least for automated accessing, handling, processing, storing, exchanging and / or maintaining the risk related physical parameters and other data / information. The risk assessment domain at least comprises a monitoring and / or assessment module for providing the risk measuring of risk exposures of the object at risk. The monitoring and / or assessment modules may be directly or indirectly connectable to the measuring / sensory devices. The risk transfer domain at least comprises a risk processing module for risk management along a risk transfer supply chain. The risk transfer domain provides a technical processing solution for example for risk transfer policy underwriting and claims management of the supply chain.

[0018] The digital network environment may for example be realized by a wired or wireless network structure, a cloud network, etc. established for example by a satellite system and distributed digital storage capacities. The digital network environment interconnects the platform modules and other digital units, components, devices, etc. relevant for the digital platform, especially the measuring / sensory devices providing physical measurement values quantifying relevant risk parameters for the automated risk transfer. The digital network environment at least provides a technical solution for electronic data exchange, for example for receiving and transferring risk related physical parameter data and information, connecting domains and modules of the digital platform and / or providing communication channels for users of the digital platform.

[0019] According to the present invention the modules of the infrastructure domain, the risk assessment domain and / or the risk transfer domain form a bonded context structure for operating the digital platform. The bonded context structure is based on a microservices architecture providing the domain modules as decentralized independent microservice modules which are distributed in the digital network environment. Advantageously, the domain modules of all the domains involved in the digital platform are realized as microservice modules loosely bonded by the microservices architecture. Two or more users can access the digital platform via user access modules provided for general access to the digital platform or for selective access to selected domains of the platform. The microservice architecture, as proposed herein, uses modular and independently scalable components. Similar to the Unix philosophy, in the present invention, each service is responsible for performing one business task, that is optimized o that task (and in particular technically optimizable) . The provided microservices are modular, loosely coupled, and highly cohesive structures. Each microservice is deployed in its own container and is run individually. The inventive system is based on smart endpoints rather than smart pipes, the used microservices providing simple queue structures, e.g. over an enterprise service bus. The componentization around the electronic services provides a structure, where a change in a component does not require a change in other services. To achieve easier enforcement of modularity, the inventive system captures the application, and the organization, around business capabilities. Further, the inventive system provides decentralized data management, where separate databases (DBs) are used for each microservice. The system comprises an infrastructure automation, where the continuous integration and continuous delivery pipelines is automated. Another technical advantage of the inventive system is in its performance robustness, i.e. its design for failure: A failure in one service does not have or has only limited affect any other services. Finally, the performance of the inventive system in regard to the various services is easier and faster than that of a monolithic system. The domain-driven architecture (DDD) of the present invention is core for efficiently extracting microservices from the domain. It is to be noted that in the inventive modular microservice architecture, the coupling is set to be low, and the cohesion is set to be high. The coupling measure focuses on evaluating the dependencies between modules and aims to reduce such dependencies, while the cohesion measure focuses on how related the functions in a module are. These two measures contradict each other; the former tries to combine the modules, while the latter tries to make them more granular. For the inventive system, coupling and cohesion are used to identify the optimal modularity (also called granularity in the microservices domain) of the functional components. To determine the optimal domain boundaries, a good starting point is to measure coupling and cohesion. Drawing the boundary that maximizes cohesion and minimizes coupling is here the best way to determine the service division. For the inventive system, the optimal microservice is set as having a balance between the minimum coupling and the maximum cohesion values. Thus, the goal achieved is the optimum selection between coupling and cohesion measurements by applying the hierarchy process. A further technical goal is to determine whether coupling and cohesion changes smoothly based on the granularity (size). For the inventive system, smaller modules not always have less coupling. Since coupling and cohesion are contradicting measures, it can be always expected for the present system, that a microservice with medium granularity is the best case that provides the best balance between coupling and cohesion values.

[0020] Again, most of the technical issues in the modularization of a monolith representing processing objects in the value chain occur on the decomposition of its domain models into the different modules, such that each one of the modules does not interdepend on a shared data repository. To partition the monolith domain model, it is necessary to consider the relationships between the domain entities that will belong to different modules. These relationships need to be replaced by invocations to the modules interface. Since circular dependencies are not allowed in the inventive modular monolith, it is necessary to decide what will be the dependency between the modules and implement their interactions using uses and notification interfaces. The implementation of these interactions requires the definition of tasks and events. Therefore, the technical effort associated with the migration effort depends on the number of relationships between the new modules' domain entities. Note that, although a domain entity may not have a direct relationship with a domain entity of another module, it may receive it as a parameter of an invocation. This is a dependence problem. So, these indirect relationships also need to be dealt with during the refactoring process.

[0021] In the inventive domain architecture two types of relations between entities are technically possible: associations, which allow for the specification of various types of multiplicities, such as one-to-one and one-to-many, and inheritance. When a superclass has subclasses that will belong to different modules, it is necessary to add all methods that are implemented in the parent class to the child classes. Therefore, similarly to the refactoring of good classes, the complexity of refactoring these methods reduces to the refactoring of the intermodules associations they use. It is concluded that all the identified types of refactoring reduce to the case of removing an association between modules. To do this refactoring, it is necessary to keep a unique identifier of the domain entity of the used module in the module that use it. This unique identifier is used by the use module to obtain a task with information of the entity, and for the used module to notify a change of its state by publishing an event. Note that, the returned task may contain unique identifiers of other domain entities, due to the indirect relationships between domain entities.

[0022] As a result, all participants in the parameter value chain and the risk transfer supply chain can easily access the digital platform for providing services, providing or retrieving data and information, working on risk transfer processing and claims handling, and all kind of digitally provided risk transfer related actions. Furthermore, participants are able to build and shape the domain modules of the digital platform, contribute to platform development and profit from existing microservice modules.

[0023] The decentralized nature of the microservices architecture allows modules to be developed and amended independently of the overarching digital platform. The microservice modules are not bound to the same technical foundation but free to use the best tools, applications or architectures to solve their specific responsibility. For example, individual microservice modules can differ in code, circuits, gateways, data meshes, etc. The microservices architecture can be leveraged not just for bonding the modules to create digital channels for the platform's services domains, wherein these modules can be provided by various participants like the users of the platform, e.g. insurance carries, insurance intermediaries and customers, or by external third-party vendors. But the microservices architecture can also be leveraged for the infrastructure domain modules and various peripheral modules of the infrastructure domain providing an operational core of the digital platform.

[0024] Since each microservice module runs technically independently, it is easier to add, remove, update or scale each of the modules. This can be done without disrupting any other microservice modules and their functionality in the system, particularly without changing any of their coding. It is possible to scale each microservice module and therefore the domains of the digital platform as needed. For example, the microservice modules can be independently adapted to larger data volumes, more compute-intensive processing, additional functionalities, etc. Further, each microservice module can be isolated from the bonded context structure of the digital platform. In case of failure of one microservice module in the microservices architecture, it is unlikely that other microservice modules of the microservices architecture fail because each microservice module runs independently. The microservices architecture prevents cascading failures within the digital platform. Due to the independence of each microservice module, any programming technology can be chosen for module development, i.e. the most suitable technology for a given module task can be selected. Further, new microservice modules can be added without redesigning other microservice modules, and therefore without conflicting with the existing digital platform. Risk transfer participants and third-party providers can efficiently add new technical features to the digital platform as needed. They can develop and deploy new features quickly and upgrade older models as new technologies allow them to evolve. At the same time, it is easy to roll back and eliminate a microservice module from the digital platform in case a microservice module does not perform as expected or is not needed any longer. Thus, unnecessary overhead of the platform can be avoided. Finally, using the microservices architecture in the digital network environment allows for accessing the microservice modules from any internet-connected device, like a computer, tablet or smartphone, regardless of its underlying operating platform.

[0025] In an embodiment variant, the microservices architecture comprises an onboarding module for on-boarding risk related microservice modules which are a proprietary product of a user, particularly an insurance provider or customer, or third- party provider by selectively bonding the risk related modules to a configuration of the microservices architecture. Users of the digital platform can develop microservice modules according to their specific needs and easily add them to the microservices architecture. Due to the independent nature of the microservice modules in the microservices architecture, it is safe to outsource certain functions of the digital platform as microservice modules to third-party partners because they do not need access to other areas of the platform to be able to design a microservice module. This is particularly helpful for risk related microservice modules like modules for risk parameter monitoring, risk assessment, risk-score generation and risk transfer, which build the technological backbone of the digital platform by exploiting diverse measuring, imaging, monitoring and other technologies for the measuring of risk exposures of the object at risk at specific locations and under specific physical conditions. The digital platform can be dynamically adjusted to changing market needs.

[0026] For example, the on-boarding module comprises an identification structure for identifying boundaries of the bonded context structure and locate connectivity links, dependencies between microservice modules and overlaps. The identification structure may be realized as domain-driven technique like Event Storming, Domain Mapping or Context Mapping. The identification structure visualizes domain events and their relationships, identifies core domains, subdomains and defines their relationships. The on-boarding module may for comprise may comprise a template for microservice modules compatible with the microservices architecture. The templates may for example include coding standards, architectural guidelines, communication protocols, deployment procedures, and any other relevant information needed to develop and integrate a new microservice based on the identified boundaries. The onboarding module may provide a structure for version control, dependency injection, and / or service discovery to ensure that new microservices can interact seamlessly with existing ones. The onboarding module may include automated integration structure and a testing structure to verify the compatibility and interoperability of new microservices with the microservices architecture. It may include security libraries, authentication mechanisms, and data protection measures to ensure that new microservices adhere to security standards and regulatory requirements. The on-boarding module helps streamline the technical process of adding new services while ensuring consistency, reliability, and adherence to the existing bonded context structure. The on-boarding module identifies key functionalities, processes, and entities of the digital platform that are involved in the risk transfer chain. It identifies areas where different users and third-party providers interact and have different requirements and terminology. By providing the users and third-party providers with a standardized, streamlined onboarding process, the on-boarding module helps accelerate development, reduce errors, and maintain technical consistency across the microservices architecture. It fosters collaboration and knowledge sharing among for efficient exchange and interaction between differing businesses as well as between businesses and customers.

[0027] Further, the microservices architecture may comprise a testing module for testing microservice modules of the microservices architecture, particularly for testing newly on-boarded microservice module. The testing module supports thorough testing of new microservice modules before rolling out to the digital network environment and monitors the performance of existing microservice modules for smooth and coordinated operation of the digital platform. The testing module validates the new microservice module with respect to technical functionality, performance, reliability, and compatibility within the microservices architecture. The testing module may comprise a testing structure that comprises several testing components. For example, the testing structure may include a unit testing structure, an integration testing structure, a contract testing structure, an end-to-end testing structure and / or a security testing structure. The unit testing structure tests individual components of the microservice module in isolation to ensure correct processing of risk related data and information. The integration testing structure verifies that the microservice module interacts correctly with other microservice modules. The contract testing structure verifies that interactions between the new microservice module and existing microservice modules adhere to predefined requirements and interfaces. The contract testing structure ensures that the new microservice module does not break other modules relying on the used interface. The end-to-end testing structure validates the functionality of the microservices architecture by testing a complete data processing flow that spans multiple microservice modules. The end-to-end testing structure simulates real user interactions and verifies that all microservice modules work together correctly. The security testing structure verifies that the microservice module is secure against common security threats, such as SQL injection, cross-site scripting (XSS), and unauthorized access. Also, the microservices architecture may comprise a documentation module for documenting information about the microservice modules collected in the microservices architecture. The documentation facilitates technical development of other microservice modules and their integration into the bonded context structure of the microservices architecture. The documented information may for example serve as a basis for the testing module, particularly for the contract testing structure, the validate compatibility of new microservice module with existing microservice modules.

[0028] In an embodiment variant, each of the microservice modules of the microservices architecture is associated to or comprises an application programming interface (API) for communication with other microservice modules and establishing the bonded context structure of the digital platform domains. The APIs define how different microservice modules interact with each other, allowing for seamless exchange. The APIs provide a communication standard for the microservice modules to enable exchange of data and requests between the microservice modules distributed in the digital network environment. For example, the communication standard can be based on messaging protocols like HTTP. The digital platform according to the invention can be individualized for each user by selectively providing access to selected microservice modules of the microservices architecture by defining API access policies for an individual user. Therefore, the digital platform can be adjusted to the functional requirements of a specific user and unnecessary functionalities can be excluded. This helps to reduce the technical overhead of the digital system provided for the specific user and ensures fast and reliable data processing.

[0029] Advantageously, the digital platform comprises an API-gateway for each user of the digital platform as a unified interface to the microservice modules of the digital platform. The API-gateway acts as a single-entry point to the microservice modules included in the customized digital platform of a respective user. It serves as an intermediary layer between the user's frontend device, such as a computer or mobile device, and the microservice modules of the microservices architecture on the backend. The API-gateway centralizes the APIs of the microservice modules to simplify access to the digital platform for the user. The API-gateway can for example be designed for request routing and access requirement enforcement. For example, some requests are simply routed to the appropriate backend microservice module, and others are handled by involving multiple microservice modules and aggregating their results. Further, the API-gateway may be designed to control authentication, authorization, monitoring, load balancing, and / or response handling. Thus, the design of the microservice modules can focus on the processing of risk related physical parameters for risk transfer related functionalities and the new release and implementation of microservice modules for the digital platform can be accelerated.

[0030] A main advantage of the microservices architecture in combination with API-gateways for each user is that sensitive data processed or developed by one microservice module can be protected from intrusions by other microservice modules. Risk transfer providers and their customers are handling sensitive data such as personal data or financial information. The API-gateways safeguard such data and information by ensuring it is only available to specifically authorized users and microservice modules. Furthermore, the microservices architecture and the API-gateways facilitate compliance under diverse data security standards.

[0031] In one example of the API-gateway, it comprises a request dispatcher component, a routing table, a path matching component and a route handler component. The request dispatcher component receives requests for access to a microservice module and determines the destination microservice module based on routing rules. It parses request metadata such as HTTP headers, request URL, or payload to make routing decisions. The routing table is a data structure that maps incoming request patterns to corresponding microservice modules. It defines routing rules and mappings used by the router to direct data traffic. The routing table may be configured statically or dynamically based on service discovery mechanisms. The path matching component parses the request URL and match it against the predefined route patterns in the routing table. It extracts route parameters and variables from the URL to determine the destination microservice module. The route handler component executes the logic associated with the matched route to the destination microservice module. It invokes the microservice module to process the request and generate a response. The route handler component may support various protocols and communication mechanisms.

[0032] In another embodiment variant of the digital platform, the bonded context structure connects two or more business entity users (B2B) and connects one or more business entity user with one or more customer user (B2C) via a subset of the microservice modules available in the bonded context structure. This provides a customized application of the digital platform. For example, the bonded context structure connects a business entity user in form of an insurance carrier with several business entity users in form of insurance intermediaries and a business entity user in form of a third-party data acquisition institution as well as a plurality of customer users in form of homeowners and / or motor vehicle owners. Thus, the digital platform according to the present invention provides a B2B2C platform, which supports risk transfer management along the full risk transfer supply chain starting from risk identification all the way to claims termination. The risk transfer supply chain is represented by the various bonded microservice modules of the microservices architecture. Particularly, the risk transfer supply chain of the digital platform at least includes microservice modules for risk transfer quoting, risk transfer policy administration, claims processing and accounting. However, the risk transfer supply chain can be individualized for each business entity and insurance customer by selecting microservice modules corresponding to required risk transfer services. Due to the bonded context structure based on decentralized independent microservice modules, the application of the digital platform is scalable to large numbers of various business entity users and customer users. A customized digital platform can be provided for each of the users by including only such microservice module that are needed for the specific platform application of the user. Thus, only such risk related physical parameters need to be processed that are relevant for a specific risk transfer evaluation or management process.

[0033] In a further embodiment variant of the digital platform, the digital network environment includes a data lake as a centralized repository for storing risk transfer related data and / or information. Instead of the microservice modules having to maintaining their own database, the data lake provides a centralized storage solution. This can simplify data governance, backup, and recovery processes and avoids the complexity associated with managing distributed databases. The data lake is integrated in the digital network environment and provides a scalable and flexible storage solution for handling diverse data requirements of the various microservice modules of the microservices architecture. Particularly, the data lake comprises a storage structure for storing and managing structured and unstructured data for accommodating diverse data types. Further, the data lake may comprise an analytics structure to support data analytics and facilitate data consolidation. The data lake consolidates data from different measuring and / or sensory devices, microservice modules, databases, and other sources. This simplifies data management and enables comprehensive analytics across the risk transfer supply chain. The data lake serves as a centralized repository for real-time data but also for historical data. For example, the microservice modules of the risk assessment domain can query the data lake to derive insights, trends, and patterns that span multiple time frames regarding data and information from monitoring and / or assessment modules and measuring / sensory devices. The data lake may also comprise a governance structure for facilitating implementation of data governance policies and data security protocols. Further, access controls, encryption, and auditing mechanisms can be applied consistently across the entire data lake. The microservice modules of the digital platform can access the data lake via the digital network environment.

[0034] In an optional embodiment variant of the digital platform, at least the infrastructure domain can be realized as a monolithic architecture comprising at least infrastructure operating components, and / or input / output components, wherein the monolithic architecture connects to the microservice architecture of the digital platform via one or more interfaces. Thus, the infrastructure domain, and in case desired components of other domains, can be realized by a legacy infrastructure as it might already be in use by some users of the digital platform according to the invention. The monolithic architecture supports the components of the infrastructure domain, and other components respectively if desired, in a single application which unifies the components in a self-contained model. Thus, critical steps in the risk transfer supply chain can be accomplished in a protected space for example to accommodate security concerns. For example, the steps of transmitting data for financial transactions or claim submission can be accomplished by the monolithic application to ensure compliance with particular requests of the users or specific regulatory requirements. The monolithic architecture supports data consistency and information protection, while microservice modules emphasize fast and flexible data and information processing. However, if possible, it is recommended to replace the monolithic architecture by a group of microservice modules providing the services of the components of the monolithic architecture to achieve a more flexible and effective platform architecture, which is easily adaptable for future demands and changing user needs. In a further embodiment variant of the digital platform, the measuring and / or sensory devices capturing risk related physical parameters for providing risk parameter measuring and information regarding an object at risk are distributed devices connected to a digital network, particularly a cloud-based digital network, and bonded to the digital network environment of the digital platform via microservices modules of the microservices architecture.

[0035] For example, the risk related physical measurement values captured by the measuring and / or sensory devices may include technical property characteristics values, environmental characteristics values, physiological characteristics values and / or statistical characteristics values. Technical property characteristics values may for example indicate an engine power of a vehicle, a heat dissipation capacity of a building, a breaking resistance of glass, etc. Environmental characteristics values may for example indicate a temperature, solar radiation force, rain capacity, snow fall, etc. Physiological characteristics values may for example indicate body temperature, blood alcohol content, heart rate, sleep rhythm, etc. Statistical characteristics values may for example indicate an average fuel consumption, an average daily temperature, a deviation from a standard oxygen level, a number of emergency stops per person, etc. All the risk related parameter values define the basis for providing risk measuring of risk exposures of the object at risk, particularly based on location and conditions associated with the object at risk and providing automated risk transfers using the digital platform of the present invention.

[0036] The measuring and / or sensory devices are for example realized as an electronic consumer product, e.g. in form of smart phones, smart watches, smart bracelets, smart glasses, smart belts etc., and may be comprising one or more measuring means for capturing for example location measurements or physiological measurements like a heart rate, steps per day, pulse rate, oxygen levels, etc. The measuring and / or sensory devices may be part of vehicle driving systems, which for example comprise measurement sensors to observe a driving behavior, e.g. by measuring speed, driving duration, deceleration period, eye movement of a driver, etc. The measuring and / or sensory devices may be part of a property surveillance system comprising cameras and other surveillance devices for measuring activities in or near a property and / or observing temperature, humidity and other environmental parameters of the property. Furthermore, the measuring and / or sensory devices may be part of weather or geographical observation systems comprising measurement devices for detecting temperature, rain, snow or hail quantity, wind force, visibility, location, terrain gradient, soil consistency, etc. In summary, any type of measuring and / or sensory device that provides sensory data comprising risk related measurements indicating a potential damage or loss related to an undesired occurrences of life risk events and / or non-life risk events, particularly of natural hazard events and / or accident related events and / or cyber risk events, that may contribute to quantifying a risk parameter of such undesired negative event is suitable for bonding to the digital network environment of the digital platform. However, the measuring and / or sensory devices need to comply with existing security requirements of the digital platform, which can be controlled by the microservice modules of the digital platform.

[0037] The measuring and / or sensory devices are an integrated technical part of the digital platform and provide the foundation for the automated risk transfers along the risk transfer supply chain by feeding risk related physical measurement data and information into the domains of the digital platform, while the microservices architecture allows for customized processing and application of the physical measurement foundation. The digital platform combines the several aspects and steps of the risk transfer processing into one easy-to-use platform.

[0038] For processing the sensory data of the captured risk related physical parameters and providing risk parameter measuring and information for the digital platform, the risk assessment domain for example comprises a risk transfer module which performs a risk transfer assessment based on the sensory data of the measuring and / or sensory devices. Further, the risk assessment domain may comprise a monitoring module designed for collecting sensory data from the measuring and / or sensory device, and an assessment module for evaluating the sensory data of the monitoring module. The risk transfer module may be designed for assigning risk factors to the plurality of the risk related physical parameters and determining a quantified overall risk score. In one example, the risk transfer module at least comprises a data input structure designed for receiving input data of physical measurement values quantifying a risk parameter captured by the measuring and / or sensory devices and a risk-transfer analyzing structure designed for processing the input data and allocating one or more risk-transfer scores quantifying the potential damage or loss, and an output signal structure providing the one or more risk-transfer scores as an output signal via the microservices architecture to the data lake or directly to the risk transfer domain. As explained above, the monitoring module, the assessment module and the risk transfer module are advantageously realized as microservice modules collected in the microservices architecture.

[0039] Thus, the risk assessment domain is able to perform automated real-time monitoring and assessment as an integrated service of the digital platform The risk transfer scores of the risk assessment domain may serve as the basis for the automated risk transfer processing and product development, which may include policy issuance, dynamic premium adjusting / pricing and / or issuance, premium collection e.g. by electronic payment transfer and signal generation, and steered claims handling.

[0040] In summary, the risk assessment domain can be used to measure and assess the risk of individual simple objects to entire portfolios of objects and complex objects. The microservice modules of the digital platform are able to combine physical measurements of measuring and sensory devices regarding environmental measurements, loss impact measurements, exposure measures and individual risk transfer characteristic. The risk transfer module can use complementary data and information received from the data lake such as background maps and satellite imagery existing data or historical data for climate change, natural catastrophic event impact, and population characteristics measures. This provides a larger data pool for enhancing the precision and reliability of the probability measures for occurrences of life risk events and / or non-life risk events and determining associated risk scores. Using the digital platform according to the invention allows to benefit from improved risk assessments for better bottom-line results based on actual physical measuring data from measuring devices, sound product development support to facilitate growth and increased data usability over the full insurance supply chain.

[0041] The digital network environment hosting the microservices architecture preferably is based on a cloud infrastructure that provides a virtualized data and computing infrastructure. The cloud infrastructure comprises a distributed collection of server components, storage components, computing components, networking components, virtual layer components and any other components required to establish the cloud-based digital network environment and run the microservices architecture. In such a digital network environment of the digital platform, the microservice modules of the microservices architecture can be realized as publicly available cloud-based application modules and as protected access cloud-based application modules that are selectively bonded by APIs or an API-gateway. The cloud infrastructure further improves flexibility of the overall technical structure of the digital platform.

[0042] To facilitate the development and connectivity of the microservice modules the microservices architecture comprises at least one JavaScript model as a js-node and / or at least one Java Virtual Machine model as a runtime environment for the microservices modules. The js-node is an Open Source, cross-platform runtime environment for executing JavaScript code and facilitates server-side programming, making it possible for developers to use JavaScript for client-side and server-side code without needing to learn an additional language. A Java Virtual Machine model is used to interpret Java code to run as a program in the microservice modules. Also, microservice modules can be deployed as containerized applications using technologies like Docker and can be orchestrated using platforms like Kubernetes to manage deployment, scaling, and lifecycle management. Automated continuous integration and deployment (CI / CD) pipelines may enable rapid and frequent deployment of microservices, with automated testing, validation, and deployment processes to ensure reliability and consistency.

[0043] The microservices architecture may comprise a communication module, which may include a number of communication components to ensure reliable, compatible, secure and accurate interaction and task accomplishment of the microservice modules. As mentioned above, the microservices architecture relies on application programming interfaces (API) as communication components for communication between the microservice modules. For example, lightweight APIs may be used, typically using protocols like HTTP / REST or messaging queues. Service-to-service communication may involve synchronous or asynchronous patterns. Asynchronous communication between microservice modules is for example facilitated by components providing messaging queues such as RabbitMQ, Apache Kafka, or Amazon SQS. A microservice module publishes messages to queues, and other microservice modules consume and process these messages asynchronously. Further, HTTP-based components may provide communication using e. g. RESTful APIs which may be employed for microservices to interact with each other. The microservice modules expose endpoints that other microservice modules can invoke via HTTP requests, typically using methods like GET, POST, PUT, and DELETE. Also, service mesh components may provide frameworks like Istio, Linkerd, or Envoy that can be used to provide a dedicated infrastructure layer for managing service-to-service communication. They handle routing, load balancing, encryption, and observability, offering features like circuit breaking, retries, and distributed tracing. A GraphQL component can be used as a query language and runtime for APIs that allows microservice modules to request precisely the data they need. A microservice module can expose GraphQL APIs to enable flexible data retrieval and composition, reducing over-fetching and under-fetching of data.

[0044] In one variant the microservices architecture can be realized as an event- driven architectures using communication components like Apache Kafka, AWS EventBridge, or Azure Event Grid and microservice modules can communicate via events. The microservice modules emit events when specific actions occur, and other microservice modules subscribe to these events to react accordingly. Further, the microservices architecture may comprise a service discovery component using mechanisms such as DNS-based discovery or service registries (e.g., Consul, Eureka) to help microservice modules locate and communicate with each other dynamically. The service discovery mechanism maintains up-to-date registries of available microservice modules and their network locations. Furthermore, circuit breaker components may be included in the microservices architecture to prevent cascading failures in microservices architecture. They monitor the health of downstream microservice modules and temporarily block requests if errors exceed a certain threshold, providing resilience against service failures.

[0045] The digital platform according to the present invention allows for fast, effective and synchronized adaption of risk transfer products and automated risk transfers along the overall risk transfer value chain to address increasingly faster changing markets, expanding customer expectations and advancing technologies. It provides alignment across state, federal, and global agencies to comply with new and changing regulations. The bonded context structure of microservice modules allows for quick and cost-effective modernization of the digital platform which frees up capital to design more engaging customer experiences, optimize distribution models, and thrive in an increasingly competitive market. The digital platform supports seamless integration and interoperability between business-critical systems of all participants, particularly ranging from business to business and business to customer communication. The digital platform prepares users for the latest cybersecurity features and techniques. The platform not only reaps the rewards of enhanced security, but also of greater scalability, which makes it easy to roll out new cybersecurity capabilities across the entire risk transfer supply chain. The digital platform provides excellent business agility and innovation capacity because microservice modules can be deployed quickly and independently, granting users freedom to rapidly develop, test, and launch new products and pivot as needed at speed.

[0046] Particularly, the digital platform enables automated risk transfers for customized risk transfer products that support the branding of business entities, leverage new distribution channels and satisfy customer needs. It optimizes the sales journey of risk transfer products for comprehensive risk transfer services and the technical accounting capabilities based on monitoring and assessment of risk related physical characteristics and parameter values regarding an object at risk.

[0047] Brief Description of the Drawings

[0048] The present invention will be explained in more detail below relying on examples and with reference to these drawings in which:

[0049] Figure l a shows a schematical illustration of an exemplary digital platform comprising an infrastructure domain, a risk assessment domain and a risk transfer domain in a bonded context structure based on a microservices architecture providing decentralized independent distributed microservice modules reflecting the risk transfer supply chain according to the invention.

[0050] Figure 1 b shows a schematical illustration of input signals providing risk related physical parameters captured by measuring and / or sensory devices providing risk parameter measuring and information regarding an object at risk for automated risk transfers provided by the digital platform of Figure l a. Figure 2 shows a diagram schematically illustrating a risk transfer supply chain as represented in the digital platform according to the invention.

[0051] Detailed Description of the Preferred Embodiments

[0052] Figure l a schematically illustrates an example application of a digital platform 1 providing automated risk transfers by processing risk related data by extracting risk-related parameter values and information regarding an object at risk. The digital platform 1 processes risk related data and / or information based on monitoring and / or assessment of risk related physical parameters captured by measuring and / or sensory devices. In the presented example, the risk related data and / or information are provided by measuring and / or sensory devices in form of a vehicle driver assistance system 2 of a first vehicle, a vehicle driver assistance system 4 of a second vehicle, a weather sensory system 6 and a property sensor system 8. Of course, many more measuring and / or sensory devices may provide risk-related parameter values of an object at risk for the digital platform 1 . The digital platform 1 extracts probability measures for occurrences of life risk events and / or non-life risk events at least comprising natural hazard events and / or accident-related events and / or cyber risk events from the monitoring and assessment of the risk related physical parameters. In the presented example, the digital platform 1 determines a probability of the occurrence of a natural hazard event in form of a thunderstorm 10 and accident-related events in form of a collision accident 12 and a building on fire 14. The digital platform 1 provides automated risk transfers by risk measuring of risk exposures of the object at risk based on location and conditions associated with the object at risk and measured by the measuring and / or sensory devices.

[0053] In summary, the sensory data captured by the measuring and / or sensory devices comprises risk measurements indicating a potential damage or loss related to an undesired occurrence of the life risk events and / or non-life risk events like the thunderstorm 10, the collision accident 12 and the house on fire 14. In general, the sensory data for example comprises physical measurement values including technical property characteristics values of motor vehicles, environmental characteristics values, physiological characteristics values of motor vehicle user, real estate characteristics values and / or statistical characteristics values for providing risk measuring of risk exposures of the object at risk based for example on location and conditions associated with the object at risk. Advantageously, the measuring and / or sensory devices can be automated real-time monitoring and surveillance means which are realized to monitor, access and capture natural hazard exposure and existence of hazardous conditions of property like vehicles and real estate. The measuring and / or sensory devices may be realized as integrated catastrophic measuring means in form of geo risk measuring tools specifically designed to provide swift measuring overviews and risk measurements and assessments of hazard exposures and occurrence probabilities, worldwide.

[0054] The digital platform 1 is based on a digital network environment 100 at least hosting an infrastructure domain 200, a risk assessment domain 300 and a risk transfer domain 400. The digital network environment 100 of the digital platform 1 is preferably realized by a virtual cloud environment 120 that is created by a cloud-based network infrastructure providing a host environment for modules of the digital platform. The digital network environment 100, for example is set up by a system of satellites 1 1 1 and ground antennas 1 12. Further, the network infrastructure may comprise server components, storage components, computing components, networking components, virtual layer components and any other components (not shown in Figure 1 a) needed to realize the digital network environment 100. The measuring and / or sensory devices capturing risk related physical parameters for providing risk parameter measuring and information are primarily distributed devices which are connected to the digital network environment 100.

[0055] Each of the domains 200, 300 and 400 comprises a plurality of modules that are designed for fulfilling specific tasks or requirements for providing the automated risk transfers for risk transfer providers, customers, third party business entities, etc. which as a whole facilitate the risk transfer for an object at risk along a specified risk transfer supply chain. In the example application of the digital platform 1 as shown in Figure l a, the infrastructure domain 100 comprises at least one operating module 202, at least one database module 204, at least one networking module 206 and at least one input / output module 208. The risk assessment domain 300 comprises at least one monitoring module 302 and at least one assessment module 304 for providing the risk measuring of risk exposures of the object at risk. Further, the risk assessment domain 300 comprises at least one risk transfer module 306 for providing risk measuring of risk exposures such as a risk score for the object at risk. The risk transfer module 306 comprises a data input structure 306.1 , a risk transfer analyzing structure 306.2 and an output signal structure 306.3. The output signal structure 306.3 generates an output signal 308 that can be transmitted to the risk transfer domain 400.

[0056] The risk assessment domain 300 may represent a risk transfer system of the digital platform 1 , wherein the risk transfer module 306 performs the risk transfer assessment based on sensory data of the measuring and / or sensory devices 2, 4, 6, 8. The risk transfer domain 400 comprises several risk processing modules performing risk transfer management tasks along the risk transfer supply chain that are specific for a risk transfer product and / or a risk transfer request of a user, for example for an insurance product and an insurance customer. In the presented example of the digital platform 1 , the risk transfer domain 400 comprises risk processing modules in form of a user access module 402, a risk transfer quoting module 404, at least one policy underwriting module 406, at least one policy administration module 408, a premium collection module 410, at least one claims processing module 412, at least one regulatory compliance module 414, at least one client communication module 416, and at least one accounting module 418. In general, as a minimum the risk transfer domain 400 comprises modules for policy underwriting and claims management, which represent the beginning of a risk transfer contract and an insurance result in form of claims handling.

[0057] The infrastructure domain 200, the risk assessment domain 300 and the risk transfer domain 400 may comprise a variety of additional and / or alternative modules corresponding to the work tasks of a specific application of the digital platform 1 . However, for conceptional simplicity of the presented example application such additional modules are not shown. An example for a more elaborated risk transfer supply chain 600 is shown in Figure 2.

[0058] According to the present invention, the modules of the infrastructure domain 200, the risk assessment domain 300 and / or the risk transfer domain 400 form a bonded context structure, which is based on a microservices architecture 500 providing the above-mentioned modules as decentralized independent microservice modules which are distributed in the digital network environment 100. The microservices architecture 500 supporting the modules of the platform domains as microservice modules allows for independent development and deployment of specific risk transfer services, enhancing agility and accelerating time- to-market for new products and functionalities. The ability to independently scale the microservice modules enables risk transfer providers to adapt to varying workloads in all areas of the risk transfer supply chain. Additionally, the flexibility in technology stack allows for the use of diverse technologies and optimizing each service for its purpose. It improves fault isolation and enhances platform and application resilience, which ensures that failures in one microservice module do not impact the entire digital platform. Microservice modules support a personalized user experience, facilitate easier integration with external systems, enable centralized data management for analytics, and offer feature specific security controls to meet compliance requirements.

[0059] Although the microservices architecture 500 is illustrated as a confined area in the cloud environment 120, it shall be understood that the microservices architecture 500 is a distributed system. Further, although the microservice modules of the platform domains 200, 300 and 400 are depicted in confined areas of the cloud environment 120, such a vicinity of the modules is not required and the microservice modules can be located anywhere that allows for access to the digital network environment 100. Further, the described allocation of microservice modules to one of the three platform domains is not binding. Rather, any of the microservice module can be attributed to another domain or more than one domain. The suggested sets of microservice modules for each of the domains shall assist in understanding the setup of the bonded concept structure of microservice modules integrated in the microservices architecture 500. The bonded concept structure is illustrated by data and information exchange arrows 510, which shall represent data and information exchange between the loosely connected microservice modules independent of their allocation to any of the three domains.

[0060] The microservices architecture may comprise an on-boarding module 502, preferably in form of a microservice module, for on-boarding risk related modules in form of microservice modules, which are a proprietary product of a user, particularly a risk transfer provider or customer, or third-party provider by adding the risk related module to the microservices architecture configuration. A risk related module for example is designed for risk sensory data collection, risk parameter monitoring, risk assessment, risk transfer quantification / quoting, risk transfer underwriting, etc. In general, a risk related module may be any module that provides a service along the risk transfer supply chain, for example the microservices architecture of the platform domains as mentioned above. For on-boarding new microservice modules in the microservices architecture 500 no coding is needed because the microservices architecture 500 supports loose connection and communication between the microservice modules. The on-boarding module 502 comprises a structure for integrating an additional microservice module seamlessly into the microservices architecture 500, as explained in detail above. Particularly, the on-boarding module 502 comprises a structure that identifies the functionality, communication standard, data interactions and dependencies of the new risk related microservice module. Further, the on-boarding module 502 comprises an interface structure for defining an application programming interface (API) contract with the new microservice module for communication with other microservice modules of the microservices architecture 500. The interface structure is for example designed to specify endpoints, data formats and authentication mechanisms, and interacts with API-gateways.

[0061] Further, the microservices architecture may comprise a testing module 504 in form of a microservice module, for testing microservice modules of the microservices architecture 500, particularly for testing newly on-boarded microservice module. The testing module 504 comprises a structure for testing the functionality and interaction of the new or existing microservice module, particularly in isolation and in interaction with other microservice modules of the microservices architecture 500, as discussed above. For example, the testing structure may include testing standards and testing metrics to assess the performance of the existing or new microservice module. Further, the testing module 504 may comprise a monitoring structure for monitoring the activities and interactions of the microservice modules of the microservices architecture 500. For example, the monitoring structure records performance, error rates, and resource usage but also captures malfunctions, irregular activities, deviation from standards, etc. The testing module 504 of the microservices architecture 500 facilitates troubleshooting, performance optimization, and platform-wide transparency.

[0062] Further, the microservices architecture may comprise a documentation module 506 for documenting information about the microservice modules collected in the microservices architecture 500. The documentation module 506 may comprise a documentation structure which allows for documenting any integration relevant 19 specifics, such as dependencies, configuration requirements, API contract requirements, exchange preferences, etc. The documentation is for example relevant for troubleshooting, easy implementation and for development of other microservice module which should interact with the microservice modules of the microservices architecture 500.

[0063] Lastly, the microservices architecture comprises a communication module 508 for interaction and task accomplishment between the microservice modules, as described in more detail above. The communication module 508 includes for example application programming interfaces (API) as communication components for communication between the microservice modules, service-to-service communication components for synchronous or asynchronous exchange, components providing messaging queues, HTTP-based components, service mesh components, GraphQL components, etc.

[0064] The digital platform 1 is accessible for users by electronic devices such as computer devices 20, 20', 20" and 20" ' shown in Figure l a. The digital platform can also be accessed by laptops, smart phones, tablet computers and similar electronic devices. In the example, each of the electronic devices communicates with an APIgateway 22, 22', 22" and 22'" as unified interface to the microservice modules of the digital platform 1 . While the microservice modules of the microservices architecture 500 may comprise individual application processing interfaces (APIs) the plurality of microservice modules of the microservices architecture 500 can be accessed by just one user API-gateway for each user. The API-gateways 22, 22', 22' ' and 22' ' ' act as a central entry point for managing, securing, and optimizing interactions between the users' electronic devices and microservice modules.

[0065] The API-gateways 22, 22', 22" and 22'" may include: (1 ) an authentication / authorization structure for controlling access to the microservices digital platform 1 , for example including validating API keys, tokens, or other credentials, (2) a routing structure for routing incoming requests from users to the appropriate microservice modules based on predefined rules which may include handling load balancing to distribute requests evenly across multiple instances of a service, (3) a protocol conversion structure for translating standard protocols of user requests to a different protocol used by microservice modules, (4) a service discovery structure for integrating service discovery mechanisms to dynamically locate and route requests to available instances of microservice modules, (5) a transformation structure for modifying requests and responses, transforming data formats and / or aggregating information from multiple microservice modules into a single response, and / or (6) an aggregation structure for aggregating data from multiple microservice modules into a single response and reducing the number of requests made by users. The structures may work together to provide a comprehensive set of functionalities that streamline the interaction between users and the microservice modules for ensuring security, performance, and maintainability in the microservices architecture 500.

[0066] In the illustrated example application of the digital platform 1 according to the invention the user accessing the platform via computer device 20 is for example an insurance provider, the user accessing the platform via computer device 20' is for example a third party provider of risk related data and / or information, the user accessing the platform via computer device 20" is for example an insurance intermediary, and the user accessing the platform via computer device 20" ' is for example a property owner looking for an insurance for an object at risk, e.g. an owner of a motor vehicle or real estate owner. The microservices architecture 500 includes microservice modules providing risk transfer services for each of these users as explained above and therefore connects business entity users (B2B) with each other as well as business entity users and customer users (B2C). The digital platform 1 is able to serve the full risk transfer supply chain from beginning to end.

[0067] In the example application of the digital platform 1 the digital network environment 100 includes a data lake 130 as a centralized repository for storing risk transfer related data and / or information. The data lake comprises several structures that collectively form a comprehensive data management infrastructure. A storage structure 132 uses for example cloud platforms like Amazon S3 or Azure for scalable data storage. An analytics structure may involve tools for batch processing and realtime streaming to bring data into the data lake 130 and for querying and analyzing data. A data governance structure 136 may incorporate governance engines for storing essential information about the stored data, providing metadata management, data lifecycle management and a data catalog of all risk related data and / or information stored in the data lake 130. An interface structure 138 may provide access control and encryption tools to ensure security and compliance. The sensory data including the risk related physical parameters for providing risk parameter measuring and information regarding an object at risk captured by the measuring and / or sensory devices 2, 4, 6 and 8 can be directly transmitted to the data lake 130 via the digital network environment 100 as input signals, as illustrated in more detail in Figure 2b. In the example, the vehicle driver assistance system 2 provides an input signal 3, the driver assistance system 4 provides an input signal 5, the weather sensory system 6 provides an input signal 7 and the property sensor system 8 provides an input signal 9. The input signal 3 of the first driver assistance system 2 for example includes a data set of measurements of parameter values related to the driving situation at the time of the collision accident 12. For example, the data set of the input signal 3 comprises a temperature value 31 , a vehicle speed value 32 and a break time value 33. The input signal 5 of the second driver assistance system 4 for example includes a data set of measurements of parameter values related to the driver situation at the time of the collision accident 12. For example, the data set of the input signal 5 comprises a body temperature value 51 , an eye movement value 52 and a hear rate value 53. The input signal 7 of the weather sensory system 6 for example includes a data set of measurements of parameter values related to the environmental situation at the time of the natural catastrophic event 10. For example, the data set of the input signal 7 comprises a rain capacity value 71 , a temperature gradient value 72 and an average hail corn size value 73. The input signal 9 of the property sensor system 8 for example includes a data set of measurements of parameter values related to the situation on the property at the time of the building on fire event 14. For example, the data set of the input signal 9 comprises entrance monitoring values 91 , a smoke detector value 92 and a sprinkler timing value 93.

[0068] All these risk related parameter values are transmitted to the data lake 130 via the digital network environment 100. In the data lake 130 the data sets are prepared and made available for processing by the microservice modules of the microservices architecture 500. For example, the data values are received by the storage structure 132. The analytics structure 134 may analyze the data and group data batches. The data governance structure 136 may add essential information about the stored and add the data batches to a data catalog of all risk related data and / or information stored in the data lake 130. The interface structure 138 may provide the data batches via and an encrypted access to a microservice module requesting risk- related parameter values and information regarding the natural catastrophic event 10, the collision accident 12 or the building on fire 14.

[0069] Additionally or alternatively, the sensory data may be provided directly to microservice modules of the digital platform 1 that are related to data processing and assessment, like for example the microservice modules of the risk assessment domain 300, particularly the monitoring module 302, the assessment module 304, but also for example to the database module 204, the claims processing module 412 or other microservice modules of the infrastructure domain 200 and the risk transfer domain 400.

[0070] In practice, the digital platform 1 receives a query from a user in form of a query input signal 24 supplied by one of the computer devices 20, 20', 20' ' or 20'", wherein the query may be related to any of the services provided along the risk transfer supply chain. For example, a homeowner sends a query input signal to the digital platform 1 and provides data about a private property and requesting a quote for a fire insurance for the home via the computer device 20" ' . The API-gateway 22'" sends the query to the computer device 20' ' of an insurance intermediate via the digital platform 1 , particularly for example via the client communication module 416. The insurance intermediate sends a quote inquiry input signal to several insurance providers and their respective computer devices 20 and 20' via the API gateway 22' ' . The insurance providers send a quote request input signal including property data and insurance specifics to the digital platform 1 via the API gateway 22. The digital platform 1 processes the quote request by applying the microservice modules related to generate a risk transfer quote for the private property, i.e. by using the data and information exchange of the bonded context structure the data of the property, its environmental conditions and its owner are processed for example by the user access module 402, the assessment module 304 requests relevant risk data from the data lake 130 and prepares the risk data for the risk transfer module 306, which generates a risk score for the home. The risk score is supplied to the policy underwriting module 406 and presented as an insurance policy draft to the homeowner as a response output signal 26 of the digital platform 1 . The query input signal 24 and the response output signal 26 can for example be entered on a keyboard, generated by the input / output module 208 and displayed on a monitor of the computer device 20" ' . The microservice modules of the digital platform 1 are able to provide risk transfer services along the full risk transfer supply chain. While the digital platform 1 preferably at least includes microservice modules for risk transfer quoting, insurance policy administration, claims processing and accounting as a simple start to end risk transfer supply chain. Nevertheless, it may include a broad variety of risk transfer modules e. g. for marketing and distributing risk transfer services, reviewing risk transfer policies, tracking premium payments, submitting loss notifications, monitoring claims, tracking progress of a risk measure improvement and so forth. However, a customized application for specific users only needs to include the microservice modules needed for their specific business model which streamlines the application concept and avoids overhead.

[0071] For a better understanding of the service options available via microservice modules of the digital platform 1 , Figure 2 illustrates a more elaborate example of a risk transfer supply chain 600. The risk transfer supply chain 600 is characterized by a B2B partner on-board unit 610, a marketing & distribution B2C unit 620, a quote & bind unit 630, a policy admin unit 640, a claims unit 650, a technical accounting & reserving unit 660, and a meta unit 670 contributing to the units 630, 640 and 650.

[0072] Just by way of example, the units may involve the following services, which can be realized as microservice modules in the microservices architecture 500 of the digital platform 1 . The B2B partner on-board unit 610 provides services for (1 ) configuration of product, pricing, terms & conditions, (2) configuration of white-label experience, and (3) partner integration. The marketing & distribution B2C unit 620 provides services for (1 ) marketing & distribution, (2) broker & channel management, (3) B2C front end processing, (4) B2C API gateway access for partners, and (5) adaptive real-time processing and proposition. The quote & bind unit 630 provides services for (1 ) assessment & underwriting like the assessment module 304 and the policy underwriting module 406, (2) quotation & contract negotiation like the risk quoting module 404, (3) editable pricing, and (4) policy issuance like the policy administration module 408. The policy admin unit 640 provides services for (1 ) cancellation, reinstatement and renewal, (2) payments, premium collection, chargeback and reconciliation like the premium collection module 410, and (3) customer communication like the client communication module 416. The claims unit 650 provides services for (1 ) FNOL & intake, (2) claim assessment, (3) claim settlement, payment & closing like the claims processing model 412, and (4) fraud checks. The technical accounting & reserving unit 660 provides services for (1 ) commission reporting, (2) internal reporting, and (3) reserving. The meta unit 670 provides services for (1 ) customer interaction & customer complaints, (2) data lake services like the data lake 130, analytics like the risk transfer module 306 and real- time monitoring like the monitoring module 302, (3) integration of country specific regulatory like the regulatory compliance module 414, third party providers, like the onboarding module 502, and fraud assessment, like the testing module 504, and (4) documents and notifications, like the documentation module 506.

[0073] List of references digital platform driver assistance system input signal

[0074] 31 temperature value

[0075] 32 vehicle speed value

[0076] 33 break time value4 driver assistance system input signal

[0077] 51 body temperature value

[0078] 52 eye movement value

[0079] 53 heart rate value weather sensory system input signal

[0080] 71 rain capacity value

[0081] 72 temperature gradient

[0082] 73 average hail corn size value property sensor system input signal

[0083] 91 entrance monitoring values

[0084] 92 smoke detector value

[0085] 93 sprinkler timing value natural catastrophic event, such as thunderstorm, hurricane and / or earthquake collision accident building on fire , 20', 20", 20'" computer device , 22', 22", 22'" API gateway query input signal response output signal 0 digital network environment

[0086] 1 1 1 satellite

[0087] 1 12 ground antenna

[0088] 120 cloud environment 130 data lake

[0089] 132 storage structure

[0090] 134 analytics structure

[0091] 136 data governance structure

[0092] 138 interface structure infrastructure domain

[0093] 202 operating module

[0094] 204 database module

[0095] 206 networking module

[0096] 208 input / output module risk assessment domain

[0097] 302 monitoring module

[0098] 304 assessment module

[0099] 306 risk transfer module

[0100] 306.1 data input structure

[0101] 306.2 risk transfer analyzing structure

[0102] 306.3 output signal structure

[0103] 308 output signal risk transfer domain

[0104] 402 user access module

[0105] 404 risk transfer quoting module

[0106] 406 underwriting module

[0107] 408 policy administration module

[0108] 410 premium collection module

[0109] 412 claims processing module

[0110] 414 regulatory compliance

[0111] 416 client communication module

[0112] 418 accounting module microservices architecture

[0113] 502 on-boarding module

[0114] 504 testing module 506 documentation module

[0115] 508 communication module

[0116] 510 data and information exchange 600 risk transfer supply chain

[0117] 610 B2B partner on-board unit

[0118] 620 marketing & distribution B2C unit

[0119] 630 quote & bind unit

[0120] 640 policy admin unit 650 claims unit

[0121] 660 technical accounting & reserving unit

[0122] 670 meta unit

Claims

Claims1. A digital platform (1 ) providing automated risk transfers by processing risk related data by extracting risk-related parameter values (31 93) and information regarding an object at risk, wherein the monitoring and / or assessment comprises probability measures for occurrences of life risk events and / or non-life risk events at least comprising natural hazard events (10) and / or accident related events (12, 14) and / or cyber risk events for providing risk measuring of risk exposures of the object at risk based on extracted risk-related parameter values (31 93) associated with the object at risk, wherein the digital platform (1 ) is based on a digital network environment (100) at least hosting an infrastructure domain (200), a risk assessment domain (300) and a risk transfer domain (400), wherein the infrastructure domain (200) at least comprises an operating module (202), a database module (204), a networking module (206), and an input / output module (208), the risk assessment domain (300) at least comprises a monitoring and / or assessment module (302, 304) for providing the risk measuring of risk exposures of the object at risk, and the risk transfer domain (400) at least comprises a risk processing module (402 418) for risk transfer management along a risk transfer supply chain (600), wherein the modules of the infrastructure domain (200), the risk assessment domain (300) and / or the risk transfer domain (400) form a bonded context structure, which is based on a microservices architecture (500) providing the modules as decentralized independent microservice modules which are distributed in the digital network environment (100).

2. A digital platform according to claim 1 , characterized in that a unique identifier of a domain entity (200 / 300 / 400) is kept for a used module by a module using it, the unique identifier being used by the module using a module to obtain a specific task, and for the used module to notify a change of its state by signaling an event.

3. A digital platform according to claim 2, characterized in that a database access index is associated to the unique identifiers of domain entities (200 / 300 / 400)exported to other modules, due to the frequent invocations to get a task object of a domain entity, given its unique identifier.

4. A digital platform according to one of the claims 2 or 3, characterized in that whenever a task is generated, by default, it is loaded with the values for all its attributes, to reduce further inter-module invocations to obtain each one of its values.

5. A digital platform according to one of the claims 2 to 4, characterized in that, after performance evaluation, larger task objects are generated, which, additionally to the attribute values, also contain information associated with several interrelated domain entities, wherein a task of a list of tasks is reducing the number of intermodule invocations when a module is interacting with a collection of domain entities (200 / 300 / 400) in another module.

6. A digital platform according to one of the claims 1 to 5, characterized in that the microservices architecture (500) comprises an on-boarding module (502) for on-boarding risk related modules which are a proprietary product of a user or third- party provider by selectively bonding the risk related module to the bonded context structure.

7. A digital platform according to claim 1 to 6, characterized in that the microservices architecture (500) comprises a testing module (504) for testing microservice modules of the microservices architecture.

8. A digital platform according to one of the claims 1 to 7, characterized in that the microservices architecture (500) comprises a documentation module (506) for documenting information about the microservice modules collected in the microservices architecture (500) .

9. A digital platform according to one of the claims 1 to 8, characterized in that the digital platform (1 ) comprises an API-gateway (22, 22', 22", 22" ') for each user as unified interface to the microservice modules of the digital platform (1 ) .

10. A digital platform according to one of the claims 1 to 9, characterized in that the bonded context structure connects two or more business entity users andconnects one or more business entity user with one or more customer user via a set of microservice modules for defining a customized application of the digital platform.1 1 . A digital platform according to one of the claims 1 to 10, characterized in that the risk transfer supply chain (600) is represented by bonded microservice modules at least comprising a risk transfer quoting module (404), a policy administration module (408), a claims processing module (412) and an accounting module (418) .

12. A digital platform according to one of the claims 1 to 1 1 , characterized in that the digital network environment (100) includes a data lake (130) as a centralized repository for storing risk-related parameter values and / or information.

13. A digital platform according to one of the claims 1 to 12, characterized in that at least the infrastructure domain (400) is realized as a monolithic architecture comprising at least infrastructure operating components, and / or input / output components, wherein the monolithic architecture connects to the microservice architecture (500) of the digital platform (1 ) via one or more interfaces.

14. A digital platform according to one of the claims 1 to 13, characterized in that the measuring and / or sensory devices (2, 4, 6, 8) capturing risk-related parameter values (31 93) for providing risk parameter measuring and information regarding an object at risk are distributed devices connected to the digital network environment (100) of the digital platform (1) via microservices modules of the microservices architecture (500) .

15. A digital platform according to one of the claims 1 to 14, characterized in that the risk assessment domain (300) comprises a risk transfer module (306) which performs a risk transfer assessment based on sensory data of risk-related parameter values (31 93) provided by input signals (3, 5, 7, 9) of the measuring and / or sensory devices (2, 4, 6, 8), wherein the sensory data comprises risk measurements indicating a potential damage or loss related to an undesired occurrences of natural hazard events (10) and / or accident related events (12, 14) and / or cyber risk events .

16. A digital platform according to claim 15, characterized in that the risk transfer module (306) at least comprises a data input structure (306.1 ) designed forreceiving input data of physical measurement values quantifying a risk parameter captured by the measuring and / or sensory devices (2, 4, 6, 8) and a risk transfer analyzing structure (306.2) designed for processing the input data and allocating one or more risk transfer scores quantifying the potential damage or loss, and an output signal structure (306.3) providing the one or more risk-transfer scores as an output signal (308) via the microservices architecture for the risk transfer domain (400) .

17. A digital platform according to one of the claims 1 to 16, characterized in that the sensory data captured by the measuring and / or sensory devices (2, 4, 6, 8) at least comprises physical measurement values including: technical property characteristics values of motor vehicles, environmental characteristics values (71 , 72, 73), physiological characteristics values of motor vehicle user (51 , 52, 53), real estate characteristics values (91 , 2, 93) and / or statistical characteristics values.

18. A digital platform according to one of the claims 1 to 17, characterized in that the microservices architecture (500) comprises publicly available cloud-based application modules and protected access cloud-based application modules that are selectively bonded by microservice modules in the digital network environment (100) .

19. A digital platform according to one of the claims 1 to 18, characterized in that the microservices architecture (500) comprises at least one JavaScript model as a js-node and / or at least one Java Virtual Machine model as a runtime environment for the microservices modules.

Images