The next case study concerns insurance contracts.
Why do we pick insurance contracts for this case study?
Well, they fall right into the bucket of the kind of legal relationships that have the if this then
that characteristic.
So if we look at an example, insurance contracts, it may be something that a farmer would want to
insure.
If there is a lack of rainfall in a particular month, that may be harmful for yields in a crop.
And the farmer may therefore suffer economic loss because the crop yields are not what they had expected.
An insurance company is prepared to take that risk.
They have data about the amount of rainfall in that location for that period, tracking back over many,
many years.
So they can analyze that risk.
The farmer is able to do the same analysis, but there is so much riding on it from the farmer's perspective
that the farmer doesn't want to take the risk that nine years out of 10, there will be rainfall, the
crops will grow and there will be a good yield.
The insurer has a big portfolio of similar risk, so they will write insurance for farmers across the
whole of the country.
And they're relying on the fact that if there's less rainfall in one place, it won't be less rainfall
in another place.
So they get premiums from all of the farmers and they only pay out in a small number of cases.
That is automatable because we have a very simple binary economic relationship.
The insurance company agrees.
If it doesn't rain during this month, it will make a payment.
The farmer agrees that the farmer will make a payment of a premium to buy the insurance upfront.
And if there is no rainfall during that period, they will receive a payment under the insurance contract
equal to there.
And the insurers agreed estimate of the loss.
So we've got that.
If this, then that if it doesn't rain, then there'll be a payment.
And the way that these are now operating through smart contracts is because the fields in the area in
question can have sensors and rain collectors fitted in them and the sensors will automatically determine
if there is rainfall.
So if they detect rainfall, then they will send an instruction back to the insurance company saying
no payment required under this contract if the whole of the month goes by with no rainfall.
Then the instruction at the end of the month will be no rainfall.
Make this transfer to this farmer's account in respect of that insured risk.
So it's a good example of where we can find automation in ordinary contract life.
And that's generally where people are looking at smart contracts, trying to find those use cases that
look like if this then that transactions there's an auditing aspect to it as well.
So we said that we've still got to, in this case, an insurance contract that's mainly written.
One of the terms of it has been converted into code.
If this, then that if no rain then made the transfer, the next stages in the development of these
kind of smart contracts is that those provisions saying if this then that are going to disappear from
the contract and simply be replaced by a reference to the code.
So we've got currently two things sitting alongside each other.
You've got the contract that says if this then that you've got the code that says if this, then that.
But they are separate.
And if there is some human error and they're written in slightly different terms, which one wins,
which one prevails?
At the moment, the courts will look to the agreement between the parties to tell them which prevails.
Does the agreement say follow the writing of a contract?
Or does it say we defer to the code at the moment because most contracts are reviewed by lawyers, either
in law firms or inside corporations?
Insurance corporations says the first looked at the language, but one of the things that we're seeing
developing through this history of smart contracts is the benefits of the efficiency of relying on the
code are being better understood.
The courts are recognizing that they may be asked to support the code over the writing, and parties
are starting to become more confident that as the early use cases are working, why do we have the writing?
The writing can be a guide for what the parties intend to agree.
But that agreements can be built into the code itself.
So smart contract audits reason for raising that is, unless you are a software developer, if you are
relying on the code and not the contract, the code is the contract.
The writing is the background to the contract.
If you're a developer, you can read that.
You can test it.
You can check it if we're a normal commercial party.
You can't say you have a requirement for a developer to do some sort of audit, often with a lawyer,
to ensure that the code is saying exactly what the contract intends it to say.
The contract here simply being short form for the intention of the parties.
So we're pushing the intention of the parties out of the writing and interest into the code.
That's the critical development that we're seeing currently.
And there's an open question in the legal community.
The lawyers need to learn how to code.
Well, not really, because there are people who do that for a living.
But lawyers do need to be able to support these smart contract audits and understand what it is that's
being translated across from writing to the software and be able to communicate clearly and without
ambiguity with the software developers.
Say that point that we had a couple of slides ago.
We have different understandings of what a smart contract is between lawyers and coders can see here
quite how unfortunate that is.
We're getting to a position where the two groups need to be working hand in hand, really understanding
each other.
Only a short time ago, we came from quite different case where we were even using the same words to
mean different things.
Again, big development has taken place over the last one or two years and will continue to develop
that that lawyers and coders will need to work together and with compliance people and risk managers
and accountants and all of the people that are in that community around economic transactions.