The IOTA Hackathon took place from Nov 17 to Nov 19 in Gdansk, Poland. Software developers from all over Europe came together to put to test the IOTA Platform with various use cases. The event was sponsored by IOTA, Baltic Data Science (blockchain and big data service), Datarella (blockchain and big data consultancy) and Bright Inventions (mobile app development). Four teams of developers and software experts formed around various use cases and competed for 4,200 IOTA in prize money.

This article describes the lessons learned by the “Freedom Pass” team, which Kira Nezu from Datarella coached. The technical part of the lessons learned can be found here “IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2)” by the team member Jonatan Bergqvist. The team placed 2nd in the competition.

1. The Task

The team was joined by Bogdan Vacusta, who brought a real-life challenge from the London Council to the IOTA Hackathon. London Councils issue “Freedom Passes” to disabled residents which allow them to use public transport within the city free of charge. Prior to the issuance of a Freedom Pass, one must obtain a doctor’s certificate to prove disability.

Pizza boxes served as flipcharts for use case scenarios

Unfortunately, scammers have successfully been photoshopping doctor’s certificates for perfectly healthy London residents. No one knows for sure how many Freedom Passes have been issued under false pretenses but the number is likely in the thousands. London Councils have no procedure in place to verify if a certificate has been faked. A simple alert, when one doctor has issued an unusually high number of certificates would be a huge step in successfully detecting fraud.  This step alone could save the public tens of millions of Pounds per year with the help of IOTA.

London Councils loose tens of millions of Pounds per year to fraud

The team’s task was to build a Proof of Concept (PoC) to prevent fraud. So, how can IOTA be used for fraud detection?

2. The Solution

The team decided to create a transaction from the doctor to the applicant, thus certifying the disability of the applicant on the IOTA Tangle. If an anomaly in the number of issued certificates of a doctor occurs, the system alerts the London Councils.

In an ideal scenario, the doctor would issue this digital certification from an app (mobile or web based), signing the transaction with her private key (this measure would actually help prevent fraud). Given the short timeframe at the IOTA Hackathon (less than 24h), the team chose to create sample data and to carry out the transaction on the doctor’s behalf for the PoC. A local database would be fed the details of the doctor and the applicant, as to identify them. So, the system for the PoC was to include the following components:

1. An input form for doctor and applicant data
2. An interface to the IOTA Tangle
3. A database with doctor and applicant data
4. A backend which analyses the data
5. A frontend for the London Councils with a list of alerts

System Architecture for fraud detection with IOTA. From the doctor’s ID and applicant’s National Insurance Number, a Seed is generated (you can think of a “Seed” as a key to access your data on IOTA).

3. The Process

Here’s is how it works:

1. Entering the data
The doctor’s and applicant’s data is entered via a web-based user interface (the team actually populated the database by writing a JavaScript method that wrote the fake data directly to the database, so this UI – although functional – was not needed for the PoC. You can learn more about this in part 2 of the lessons learned):

User interface for entering application data

2. Certification
The data is written to the local database. Simultaneously a transaction – symbolizing the disability certificate – from the doctor to the applicant is immutably written to the IOTA Tangle. The transaction ID is, in turn, written to the local database adding the ability to prove that the certification has taken place.

3. Analysis & Reporting
The backend analyses the data and alerts the officials in case of any anomalies. ie. (If one doctor has issued unusually many certificates within a certain time frame.)

Anomaly report for issues doctor’s certificates

What we learned

We completed our goal within the timeframe despite running into issues due to working with an immature system along the way.  In the end, we managed to create a Proof of Concept perfectly suitable for the setting of the IOTA Hackathon.

We did run into a few issues along the way which must be addressed by the IOTA team in order to improve the system and make it fit for future use cases:

Speed of transactions: On the IOTA testnet we experienced long wait times when confirming transactions. Submitted transactions confirmed in ~1 minute, reading transactions took circa ~3-5 minutes or more depending on the amount of data. This may be a testnet issue independent of the mainnet.

The Documentation was not up to date, there was missing information and what documentation existed was somtimes misleading (i.e. Properties marked as optional are actually required, not obvious that a replayTransaction function creates a completely new transaction, sending a message instead of a transaction the sender is not documented on the tangle …)

Releases are not scheduled in advance, if an update is run during development, developers must adapt quickly to accommodate changes. A roadmap by IOTA for releases would be very helpful.

Node.js SDK is based on “callbacks” (an old technology standard), not on “promises” (current technology standard).

The API can easily be misused. Values and properties that shouldn’t be passed can go through without any error message. The API is missing descriptive error messages, leaving developers in the dark when it comes to hunting down bugs.

So, why IOTA?

Frist off, one might argue that this task could have been done with a regular database entirely. While this is true, a database is a lot easier to attack by hackers than a blockchain or tangle. Also, this kind of system could have been set up on a blockchain system s.a. Ethereum, why use IOTA? Well, the challenges blockchain systems are struggling to overcome are performance and scalability. Due to block sizes, transaction times constantly increase – thus making the systems less usable for scenarios in which transactions must happen near instantly.

IOTA helps to solve the problems of performance and speed of transactions. The team is in agreement that the IOTA Tangle and similar “non-block” chain approaches are likely to be most feasible to enable scalability in future. Also, an application using IOTA can quite easily be transferred to related use cases.

Conclusion

Would the team recommend using IOTA for fraud prevention?
The answer is Yes, if the long term goal is to further develop IOTA in general. The answer is No, if the system should be used in a productive environment at this point, since it is still immature. Alternative systems which currently are more mature and could be used for the task include Hyperledger Fabric, Sovrin and Ethereum. These blockchain systems pose scalability issues in the future, whereas development here is also ongoing.

The IOTA application “Freedom Pass” is very well scalable and transferable to related use cases. However, IOTA must undertake massive improvements regarding performance s.a. speed and documentation as well as for the API and SDK/node.js. If the above issues are continuously improved, the team recommends IOTA for further developing this kind of system for the public. IOTA promises future potential for the public for reconciliation of data, reduction of duplication, auditability, authentication.

Team “Freedom Pass” at the IOTA Hackathon in Gdansk (from left to right): Michał Łukasiewicz, Kira Nezu, Bogdan Vacusta, Jonatan Bergqvist, Victor Naumik, Rafal Hofman, Artem Goncharenko

Continue to the technical report by Jonatan Bergqvist:
“IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2)”