The problem Defraud solves

Problems:

• Many transactions: less effective control
• At least 5 documents are sended between actors: confirm the identity, prove the fraud, verify the transaction and when sending the refund
• Actors and step-by-step progress: this process involves 5 actors (Banks, Clients, Retailers, Refunder (often the bank group), Police authority), all have to wait to act one after the other, and some retailers refund their customers and never get their money back
• Time: a complete processing between 1 week and 6 months

Solutions:

• Actors management: 5 actors, 3 capabilities in the module
• Funds management: the refund is stored on the contract and several conditions must be met to recover the funds
• Security: access to the contract is highly controlled, very few cheating possible, none of them without a signature
• Speed: from 1 week to 6 months to… 1 day at best
• Documents: from 5 documents to none required

Challenges I ran into

Designing the structure of the module was difficult. The fraud_trasac object needs to be able to change ownership, have several accessors, but also to have very secure access. I didn't manage to finish the front-end because some functions like "amount" don't work, but the template i created and provided for the Customer page is an example of what I would have liked to do for my entire MVP. However, I still managed to build almost the entire part of the project with a viable structure (except some functions..).