I was recently confronted by a law case, where jurisdictions and laws from China, Switzerland, Australia and the US overlapped and contradicted each other. The case was about a contract which one party claimed to be legal, while the other party claimed it was not and therefor such an agreement was never reached (since under their jurisdiction such a contract did not exist).
This got me thinking: If I now choose to launch a global macro hedge fund over an ethereum DAP and issuing Smart Contracts from Switzerland (since Ethereum itself is registered in Switzerland) and investors from China, and the US would approach the fund and invest, under which regulatory jurisdiction would it fall? Of course law has (in the greater part of the world) not yet adapted to cryptocurrency, or Peer-to-Peer blockchain technology, but are there any interest groups yet in existence, focusing on this problem, especially since Ethereum will be extremly influenced by current areas of jurisdiction?
0 ·
Comments
3y3 vvander
how mvch longer
IT will take,
before
global society
collectively
fvlly
Vnderstands:
CODE IS LAW.
Still, these are complicated questions when you're dealing with electronic communication and transactions involving multiple jurisdictions. It's no guarantee, but one way to address the issue and create more contract certainty is to include choice of law and venue provisions in transactional documents. (I am a lawyer but this is not intended to be legal advice -- talk to your own legal team to sort out what works best for your use case). However, just because you say a court has jurisdiction doesn't mean it will take it. A couple of years ago I had a case involved a non-US transaction where the parties agreed to jurisdiction in the Southern District of New York. The Court dismissed the case because the parties had no connection to it.
Similarly, you can agree to use a certain jurisdiction's law but if applying it would be contrary to public policy of that jurisdiction (a three month statue of limitations in a fire insurance policy, for example) the court won't apply. Same is true of private arbitration -- you have to look at the parties and potentially implicated jurisdictions to decide if and how arbitration clauses will be enforced.
The good news is that this sort of question can usually be identified up-front and provisions made that handle most cases.
Still, let's assume that you're 100 percent correct. It's still useful to distinguish between (1) terms that parties agree to and (2) the legal/regulatory framework in which they exist (which remain very much off chain). Why? Sure, you may be able to reach an agreement with another person and put it all into code without worrying about jurisdiction or interpretation. Telling regulators like the SEC, FTC, IRS or their equivalents (take your pick) that you've chosen to ignore jurisdiction while raising funds for a hedge fund could be a dicey proposition.
Significantly this would also put economic pressure on governments not to limit ethereum legally. The more they do the less blocks will be completed in their country, the less ethereum mined, the less wealth created. A big disincentive to abuse regulation.
I have misgivings about this because it smacks of the way businesses like Amazon and Starbucks avoid tax in the UK. But it is equitable. I'm sure the UK government would review their policies if Joe plumber and Bob the builder were avoiding tax as well as Amazon and Google.
Good trading signals will always have value. But in near zero cost frictionless ethereum market places, I see no room for high volume discounts or old boys network advantages.
As such hedge funds would be reduced to selling trading signals that individual accounts could automatically act on and take liability for. Im pretty sure that anyone can already setup a subscription service offering trading signals without SEC or FCA regulation. Moreover any entity using the current hedge fund model will be uncompetitive due to the additional costs of managing regulation. It's one of the many advantages of near zero costs marketplaces.
The first problem I see with this is that the contract may have to wait a very long time before a block happens to complete within it's required jurisdiction.
If the Ethereum platform was altered to avoid this so that a certain number of blocks had to be completed within jurisdictions required by current contracts, then this would be gameable. You could create a contract that insists on executing only in a small jurisdiction (eg: Jersey or the Cayman Islands), and then run a batch of miners there winning an advantageous number of blocks.
I much prefer my second idea of doing away with the hedge fund! I agree that they have very little value beyond weight of money/influence, and that is exactly why they can be sidestepped in near zero cost markets. I suspect that in a lot of sectors what may at first appear to be legal issues can be solved as architectural/technology issues. That is why Ethereum is so wonderfully disruptive.
An old school way of dealing with this issue is to fence the transaction in and limit access to people in particular places -- you get licensed as an insurance company in Foobar and only allow residents of Foobar to participate in "insurance" transactions. You comply with reserving and claims requirements, (many of which actually serve in my experience a useful public purpose and keep insurance companies from acting badly). A regulator in another country can't bother you because you're not engaging in insurance business there, or with its citizens.
I think I see how you get rid of the 'hedge fund' concept (and associated regulation) by selling information directly and not holding capital or paying returns -- you're cutting out the middleman, but not a fund of investment capital. That's intriguing (if I understand your point). Maybe like an S & P or Moody's but not in anyone's particular control. Similar approach for insurance? Not holding premiums, but selling information?
And yes, I do see an ethereum hedge fund just selling information. Of course this would be directly to other customer ethereum contracts, which the client would have elected to allow automatic trading of the hedgies signals.
This is already possible with existing technology. The difference is that I see an opportunity for near zero transaction and spread costs in ethereum markets. It is this that threatens the existing institutional fund models, because there is no longer an economy of scale advantage to the client in using a large fund.
As you suggest, let's apply this to the insurance industry. Actuaries become information providers (and possibly arbitrators), individuals insure individuals peer to peer based on actuarial data feeds, and their own discretion. Centralization risks (Lloyds, aig) disappear. How do the regulators treat a situation where individuals are insuring each other privately without running a business?
Personal lines coverage isn't going to be replaced by p2p transactions in the near future for a variety of structural reasons. Auto insurance (in the US, and I assume in most jurisdictions that require it) must be written on approved forms and in many US states has mandatory minimum limits requirements. Mortgage lenders require homeowners insurance, also on specific forms and insurers have to satisfy certain standards -- admitted paper, particular bond rating, etc. So, like Banks, insurance companies aren't going anywhere for a while. (Whether that's a good thing or a bad thing is another question).
But to your (intriguing) point -- what non-commercial risks would people ('natural persons' or 'individuals') transfer in exchange for value on a p2p basis?
First idea. What if a smart contract friendly but regulator approved insurance company offered very low cost insurance services if the holder can show they are already underwritten by an ethereum smart contract?
Essentially they would provide minimal premium insurance with an extremely high excess, fully covered by a smart contract. Their contract would pay out based on the same conditions as the smart contract. The insurance company could accept certain specified existing smart contracts, or could offer to source them for the client. A small insurance firm could go to the ethereum market rather than the usual few city brokers, and as such could be extremely competitive.
What would the regulatory implications of this model be? Could existing companies enter the market easily just by raising their excess and lowering their premium without any new regulatory attention?
A second idea. A great entry market would be excess protection coverage, which would completely avoid insurance companies and regulators as far as I can tell.
Example, if I hire a car from Enterprise Cars it can cost me 700 to 1000 in excess (bitter personal experience!). They offer exorbitant optional excess protection at 12 per day for 600 in cover. All I would need for more cost effective peer-to-peer cover is a car hire contract and related excess bill both dated after the smart contract to prove entitlement. It is so unambiguous, it would rarely need arbitration, and if so it could be cheap and flat fee. The same could apply to standard car insurance. In fact any insurance with nasty excess fees or claims penalties- so nearly all of it. I like this idea because I know I would use it!
Applications like this would get people used to the technology, make money for enterprising start-ups, and ask very difficult questions of the existing system.
These are great ideas; well thought out.
I see an analogy in the use of captives for workers compensation insurance. Most US jurisdictions require workers comp policies to to be written on admitted paper, with particular bond ratings -- there's a public policy concern that underlies this: if you're going to require wc coverage and provide protection from lawsuits in exchange, the state wants to be certain that people provide "real insurance" that will actually pay claims, and that a guarantee fund won't be on the hook instead. There's a workaround for captives -- fronting paper backed by an LOC. The fronting carrier is a real insurer and obligated to pay if the captive doesn't, but the payment obligation is backed by collateral and in most instances the captive pays. While the captive has to satisfy captive insurance regulatory requirements, in effect, it doesn't have to be a workers compensation insurer to self insure workers comp risk. (This is a bit of an over-simplification, and works differently in different jurisdictions, but it's the general idea.)
I think you're on to something -- use traditional insurance as a backstop initially: either as reinsurance, excess/dic with a drop-down feature. Or offer p2p coverage excess of traditional insurance, like your car rental scenario. That could work. The key is making sure that there's "real insurance" in place to satisfy legal requirements. I'd also start with one or two specific verticals (like the rental car scenario) rather than trying to capture all of insurance. They key might be a real insurance company backing the product -- either a newly created one, which satisfies every legal requirement, or an existing company that buys into the product and underwrites it.
(Another analogy? There's a product in the construction market that offers guaranteed payment of a certain of the total amount of any claim that an insurance company pays. The idea is that in any claim there will always be items that aren't covered but that are related to the loss. Rather than forcing insureds to file another proof of claim and argue about what is/isn't covered, this product is suppose to pay when you're paid.)
But there is a problem.
The reason car hire firms (and insurance companies generally) charge an excess is to discourage claims.
If I insure the excess on car hire, it could be argued I am incentivizing accidents, or at least claims. But in ethereum this problem would be far worse. I could over-insure the excess many times with different peers, deliberately bump the car into a lamppost, and profit on the claim.
This is a problem because it turns positive insurance into negative insurance. I am being rewarded for bad things happening which are under my control. Frankly I wouldn't want any part in a technology that incentivized this.
You could attempt to solve it by publishing hashes of the customer's id (eg national insurance/passport number) of which at least one is required, along with one or more service categories, and a date range eg: hash of passport number, insurance > excess > car hire, 26 Sep 2014, 5 Oct 2014. This is nice because the kyc contract never knows the customer details, just the hashes.
This would be a separate and generic kyc contract that would be paid for entirely by the update and search transactions using it. Insurance contracts would be highly incentivized to use and update it or risk failure due to false claims. A generic kyc contract is vital to this and many other sectors. Has there been discussion of this elsewhere?
update:
problem- car hire firms will quickly learn to update the kyc contract and block any attempt to take out further insurance, but to make a valid ethereum claim you will need to secure the smart contract before the hire anyway so perhaps not. Then again having got your details they could just keep blocking you permanently.
Instead of generic kyc, insurance contracts might just need to be aware of all other insurance contracts, and interrogate them for existing claims, preferably through a standard insurance contract api. As stated if they don't they will be bound to fail as they will fail their insurers. Hmmm might actually be a good thing as it will incentivize insurance companies to update their details on ethereum or lose out in the same way.
I agree with you that the block-chain validation should be attractive to insurers -- they already share claim information. Tracking additional insured coverage is a major headache (and source of dispute) across the board anyway. The challenge is finding insurance markets who are forward thinking enough to get it.
But the point here is that insurance companies will be incentivized to publish this data on Ethereum themselves (or open it up to independent ethereum arbitrators). If they don't, the ethereum contract and the insurance company both lose out equally to over insurance scams (a bad actor insuring the excess twice, once with a company, once with a smart contract).
In other words, just the existence of ethereum insurance means that they will suffer bad claims if they ignore it.
Better yet, it also incentivizes them not to update ethereum with bogus contract data to prevent ethereum contracts from insuring, because they will have to use the same data themselves.
In this case the data will need to be anonymized, so they can't detect if an existing contract is one of their own bogus entries, or someone else's valid claim.
So we're probably back to the centralized kyc contract so it can anonymize sources.
Edit:
Problem. I am assuming the insurance company loses on the claim. But if the excess is high they may actually benefit from a claim. So my idea of excess insurance for existing insurance contracts wouldn't incentivize insurance companies to interact. Other insurance types still could.
How to proceed? You can find a sliver of the insurance market (maybe it's in the car rental space) and a couple of participants (car rental companies?)[2], and work out the details as you go. Set the right premium, include the right conditions, require a sworn proof of loss (under penalty of perjury) that attests that the loss hasn't been covered by another instrument, and then iterate.
Interesting!
[1]. As an aside, I'm not sure that over-insurance necessarily hurts insurers. Maybe. The theoretical response is that there's a moral hazard risk: if you have "too much" coverage, you might have less incentive to avoid a loss or (for truly bad actors) cause it yourself. The mere fact that someone is paid more than the amount of a loss doesn't mean that an insurance company is harmed, as long as they've priced the risk properly. And your perspective regarding the amount of loss very frequently depends on whether you're the insurer or the insured. Is it the depreciated value of an item? Does it include overhead and profit? Betterment? Actual cash value? Replacement value? Blah blah blah. Etc. etc. etc. The complexity creates opportunities, incidentally -- I'm not raising them as impediments. Each one of these issues is a problem that needs a solution, some of which ledger based transactions may help resolve in whole or part.
[2]. Could be a potential anti-trust/competition issue to be mindful of, depending on information shared in an underwriting ledger. If it's just amount of coverage, without information about market or premium (which I can't imagine insurers want to share anyway) maybe that's a non-issue. Not an antitrust lawyer, footnotes notwithstanding
If I develop a library of distributed functions and locate the class of financial transactions to a fixed region of Dapps that should fix the jurisdiction to that locale. This is especially true if I am only renting access to information NOT selling it!
What do you think?