Title: Development of Decentralized Applications (Dapps) Using Blockchain Technology to Improve the Insurance Process in Malaysia. It is hereby certified that LAAN WEI YI (ID No:19ACB01708) has completed this final year project titled "Development Of Decentralized Apps (Dapps) Using Blockchain Technology To Improve Insurance Process In Malaysia" under the supervision of Mr. I declare that this report titled "DEVELOPMENT OF DECENTRALIZED APPLICATIONS (DAPPS) USING BLOCKCHAIN TECHNOLOGY TO IMPROVE INSURANCE PROCESS IN MALAYSIA" is my own work except as cited in the references.
LIST OF TABLES
INTRODUCTION
- Problem Statement and Motivation
- Problem Objective
- Project Scope and Direction
- Contributions
Rules can be pre-defined in a smart contract, such as an image of proven window damage and a receipt from a selected panel shop, the claim will be paid out automatically. In addition, duplicate claim or claim fraud can be reduced as all transactions that occur in the chain are recorded and immutable. From the insurer's perspective, the identity of the user will be verified and the claims trail can be found in the blockchain, which is believed to reduce claims fraud in the industry.
LITERATURE REVIEWS
- Review of technology .1 Insurance
- Blockchain
- Consensus Mechanism
- Smart Contract
- Application of blockchain in insurance
- Review of existing systems .1 Takaful Motor Insurance
- Etherisc Flight Delay Insurance Decentralized Application
- Lemonade
- CAIPY car insurance policy framework
- CioSy
- Comparison
A smart contract is self-executing code installed on the Ethereum blockchain that can automate business logic. The insurance policy through the smart contract will confirm the initial coverage for the loss and inform the insurance company in real time. The update to the claim detection URL feature will be triggered by an API update in the Insurance Pool smart contract.
- System Architecture Diagram
- Use case
- Activity Diagram
Use Case Name: Create Policy Offer ID: 1 Relevance Level: Main Key Actor: Insurer Use Case Type: Detail, Core Stakeholder and Interest: Insurer – wants to offer new insurance products. Use Case Name: Get Quote ID: 2 Severity Level: Main Key Actor: User Case Type: Detail, Core Stakeholder and Interest: User – wants to get quote. Use Case Name: Purchase Policy ID: 3 Relevance Level: Main Key Actor: User Case Type: Detail, Core Stakeholder and Interest: User – wants to buy policy.
Use Case Name: Create Claim ID: 5 Stake Level: High Primary Actor: User Use Case Type: Detail, Key Stakeholder and Stake: User – wants to make a claim. Use Case Name: Approve Claim ID: 7 Stake Level: High Primary Actor: Insurer Use Case Type: Detail, Key Stakeholder and Interest: Insurer – wants to approve claim. Use Case Name: Verify Claim ID: 6 Stake Level: High Primary Actor: Panel Workshop, Police Use Case Type: Detail, Key Stakeholder and Interest: Panel Workshop, Police - Verify the claim submitted.
After the user enters vehicle information, our system retrieves chain records from third-party providers to verify ownership of the vehicle. The specified user address must be registered under the vehicle number to ensure the validity of the policy. If the user has sufficient amount of Ether to pay the premium, he will pass the verification to a successful purchase, which also means that he has successfully registered in the smart contract of the policy. Claim will only be successfully initiated when the vehicle has purchased policy and within the policy period.
After the user submits, our application will automatically distribute the claim request to the panel workshop and police department for further verification.
SYSTEM DESIGN
- System Flow Diagram
- System Components Specification
- System Components Interaction Operation
Since data is stored on blockchain, data will therefore be processed and transferred via smart contract. Create policy offer will request data from insurer and pass to policy contract to create settlement and mapping for the offer and push to blockchain network. After information is verified, premium will be calculated based on user input and vehicle information.
The purchase policy will be triggered when the user pays the premium on the offer summary page. The policy data will be written into the fields of the policy holder lists and mapping and pushed to the blockchain network. Request Claim will request claim information from the user and policyholder information to verify your claim.
Once the claim is verified, the claim data will be passed to the claim contract to create claim list and map pools and push the data to the blockchain network. When an application request is initiated, the application request will be completed in the police and panel workshop system. View Policy will query the list of policy holders from the policy contract to build the policy list interface.
View Claim will request a list of claims from the claims contract to build a claim list interface.
SYSTEM IMPLEMENATATION 5.1 Methodology
Initial requirements
Design
Build initial prototype
Customer Evaluation
Review and update
- Hardware Setup
- Software Setup
- Settings and Configuration
- System Operation (with Screenshot)
- InsuranceDapp
- MyGov
- Police
- Panel Workshop
To interact with the third party smart contract, the insurance administrator will need to obtain their contract address and connect to our contract as shown in Figure 5.4.1.7 and Figure 5.4.1.8. By clicking the policy index, the application will navigate to the administrator to view the policy details as Figure 5.4.1.13. By clicking the claim index, the application will navigate from the admin to view the claim details as figure 5.4.1.15.
When the user clicks the CTA button to request a quote, the user will be redirected to this page as shown in Figure 5.4.1.20. With all the given data, a summary of the offer will be compiled, as shown in Figure 5.4.1.21, and displayed to the user. By clicking on “View” of each record, the MyGov administrator will be able to view the details of the record as shown in Figure 5.4.3.2.
By clicking "View" on each record, the police will be able to view the details of the record as shown in Figure 5.4.4.3. Police can navigate to the Create Record page as shown in Figure 5.4.4.4 via the 'Create New Record' button on the top navigation bar. When there is a claim request pending police verification, it will be displayed in the list as shown in figure 5.4.4.5, otherwise it will show "No pending verification request" as shown in figure 5.4.5.5.
By clicking on “View” of each record, the panel workshop administrator will be able to view the details of the record as shown in Figure 5.4.5.3. The Panel Workshop Administrator can navigate to the Create Record page as shown in Figure 5.4.5.4 through the “Create New Record” button. When a claim request is pending to be verified by the panel workshop, it will have a similar process flow as shown in Figure 5.4.4.5 and Figure 5.4.4.6.
SYSTEM EVALUATION AND DISCUSSION
- System Testing and Performance Metrics
Insurer view policy offering
Insurance Dapp System Test (Insurer) .. required test case Expected results Test data Case 3: View insurer report.
Insurer view policy analysis
Insurer view claim analysis
Insurance Dapp System Test (User) .. required Test Case Expected Results Test Data Case 1: User can request quote.
Customer view policy purchased
User initiate claim request
User view specific claim request
JPJ admin view specific record
MyGov admin view specific record
Police view record created
Police view specific record
Police approve verification claim request
Panel Workshop admin view record created
Panel Workshop admin view specific record
Panel Workshop admin approve verification claim request
- Testing Setup and Results
- Project Challenges
- Objectives Evaluation
Example 1 and Example 2: Panel workshop administrator can create a new accident record and view the created record. Additionally, the initial development of blockchain technology focuses on cryptocurrencies rather than a decentralized application. Because the different tutorials and solutions we refer to will have major syntax differences, requiring us to change the entire code structure.
Figure A-5 and Figure A-6 show a similar tendency that most of our respondents have high confidence in the immutability and auditability characteristics of blockchain. On the other hand, 37.5% of our respondents prefer to do business with an agent and 53.3% of them will only consider a purchase if the policy is simple and understandable. 75% of them indicate that the acceptance and claim process often takes a long time to process and 65% of them indicate that too much paperwork information is requested during the process.
25% of our respondents have security concerns about automation and a small portion of them (12.5%) still prefer to deal with agents. To have more security assurance, transparency throughout the process is crucial, as figure A-15 and figure A-16 show that they believe with high transparency intentional unsuccessful claim rate will be reduced and they can have more control over their data. Finally, our application can provide more efficient insurance process with less paperwork and document required as all process will be handled by smart contract.
Blockchain technology that decentralizes every process in insurance domain is the key of our application.
CONCLUSION AND RECOMMENDATION
- Conclusion
- Recommendation
To summarize everything, our application will consist of the basic functionality of traditional insurance, but we will improve it by implementing it in the blockchain network. The first recommendation is to use a vehicle API that can retrieve data on Malaysian registered vehicles as an alternative to the JPJ data provider we created. The APIs we recommend are Vehicle API - Malaysia (vehicleapi.com.my) and Octofacts (https://otofacts.com/api/).
Vehicle API is a global vehicle license plate lookup API that supports a wide variety of programming environments and programming languages. It provides up to 20 data fields such as vehicle model, vehicle specification, registration date, etc. Data returned from this API is the insurer history report and vehicle history report and each report costs RM6.
Insurer History Report will return data fields such as policy number, policy period, current insurer and type of coverage. While vehicle history report will return data for example stolen check and total loss check. The above APIs require capital to perform testing and development, so we create a JPJ 3rd party as data provider for our application.
This technology requires a different domain of knowledge and therefore it is not implemented in your project.
APPENDIX
Objective Evaluation Survey
FINAL YEAR PROJECT WEEKLY REPORT
- WORK DONE: Project timeline planning
- WORK TO BE DONE: Study FYP1 and identify changes
- PROBLEMS ENCOUNTERED: No issue
- SELF EVALUATION OF THE PROGRESS: Project is on scheduled
- WORK DONE: Created FYP2 report based on template given
- WORK TO BE DONE: Migrate and combine FYP1 report to FYP
- WORK DONE: Complete combination of previous report to current report
- WORK TO BE DONE: Content improvement for report
- WORK DONE: Complete content enhancement in the report
- WORK TO BE DONE: Draw system diagram and complete new added section for FYP2 report
- WORK DONE: Complete all drawings and elaboration
- WORK TO BE DONE: Continue on new report section
- PROBLEMS ENCOUNTERED: New section is out of expectation, need to spend extra time than planning to complete
- SELF EVALUATION OF THE PROGRESS: Need to be more focus on new section
- WORK DONE: Completed new section and draft of survey
- WORK TO BE DONE: Distribute survey and start system development
- WORK DONE: Developed View Policy features
- WORK TO BE DONE: Development of Request Claim features
- WORK DONE: Undergoing development of Request Claim features
- WORK TO BE DONE: Complete development of request claim and conclude survey results
- WORK TO BE DONE: Proceed with Verify Claim module
- WORK DONE: 50% Verfiy Claim module
- WORK TO BE DONE: Complete development of Verfiy Claim module and proceed with last module Claim Approval module
- WORK DONE: Complete report writing and Claim Approval module
- WORK TO BE DONE: Test on bugs for current works and FYP submission
- WORK DONE: Finalise system and submit report
- WORK TO BE DONE: Prepare presentation
Project title: Development of decentralized applications (DApps) using Blockchain technology to improve the insurance process in Malaysia. TODO: Draw the system diagram and complete the new section added for the FYP2 report. CAUSED PROBLEMS: The new section is out of expectation, you have to spend more time than planned to complete it.
WORK TO BE DONE: Complete the development of the Verify Claim module and continue with the final Claim Approval module.
POSTER
PLAGIARISM CHECK RESULT
Title of last year project development of decentralized apps (DApps) using Blockchain technology to improve the insurance process in Malaysia. Required originality parameters and limits approved by UTAR are as follows:. i) Overall similarity index is 20% and below, and. ii) Matching of individual cited sources must be less than 3% each, and (iii) Matching texts in consecutive block must not exceed 8 words. Note: Parameters (i) – (ii) must exclude citations, bibliography and text matches that are less than 8 words.
Note The Supervisor/Candidate(s) must/are required to provide the Faculty/Institute with a full copy of the complete set of originality report. Based on the above results, I declare that I am satisfied with the authenticity of the Final Year Project Report submitted by my student(s) as mentioned above. Form title: Supervisor's Comments on Originality Report Generated by Turnitin for submission of Final Year Project Report (for Undergraduate Programs).
FYP2 CHECKLIST
UNIVERSITI TUNKU ABDUL RAHMAN FACULTY OF INFORMATION & COMMUNICATION
TECHNOLOGY (KAMPAR CAMPUS)
