A Proposal for Automated Online Dispute Resolution, Part 1

This essay proposes a set of draft standards for automated online dispute resolution (AODR). The drafts I propose here are for transactional disputes, and specifically for AODR that generates arbitral awards in the millions of claims for debt and breach of contract. This proposal does not consider AODR for torts or disputes with non-AODR-compliant evidence or claims.

The AODR promise is simple and a little mind-boggling:

• Take millions of claims out of the court system.
• Reduce cost of dispute resolution (pre-enforcement) to zero.
• Increase speed of dispute resolution (pre-enforcement) to infinity (limited only by bandwidth and machine capacity).
• Give a previously unheard-of stimulus to economic activity due to a drop in transaction costs.

AODR is technologically and legally possible today. In jurisdictions such as Ontario, Canada, AODR does not require any new laws, government funding or approval, and adversarial court proceedings. I am one of the people working on AODR now, and my goal is to help build an AODR community that can turn these or other drafts into industry standards.

There is a simple reason why AODR is possible today. Litigation consists of three parts: proving facts, determining the applicable law, applying the law to the facts. Any disagreement on any of these steps will give rise to an issue that the court will have to hear and resolve. A great body of civil procedure kicks in before and during such hearings—all because humans tell different stories, and justice requires hearing all reasonable stories.

When facts are simple enough (as they are in many transactions) digital signatures and uniform transaction records deposited into digital escrow eliminate disagreements over facts (and kill stories, alas). The technology to support this exists.

When the law is straightforward (as it is in many transactions, especially if evidence is not in dispute), the law and its application can often be reduced to formulas (loans, interest rates, invoices, payments and so on). If you are familiar with liquidated damages and if you ever had to obtain default judgments, you will probably recognize this.

But without AODR, a bank or a vendor needs to hire a legal professional, who will probably type a claim into a Word document, print it and send it to a courthouse. The plaintiff’s agent will then need to physically present a copy of the filed claim to the defendant (who may be evading service). Often, debtors do not file a defence, and creditors get default judgments. Creditors certainly hope this will happen because the alternative is waiting a few months for a trial or a summary judgment motion which the creditor will win at great expense. Of course, default judgments are tenuous and not final. Defendants can set them aside if there is no good reason to override the normal bias in favour of a hearing on the merits.

Unlike default judgments, AODR awards are final. AODR claims are served electronically and unambiguously. AODR awards are calculable rather than arguable because parties must structure their pre-dispute transactions in an AODR-compliant way to be eligible for AODR. AODR is a creditor/vendor dream, truly. But every responsible economic player will like AODR because it will reduce prices and improve access to credit. Also, there are no attorney’s fees or costs in AODR awards (because AODR cost is zero or negligible), which should make debtors happy.

A draft standard for an automated online dispute resolution system (AODRS)

1. AODRS will not require a hearing of the dispute in the courts.
2. AODRS will require a binding arbitration regime in the jurisdiction (such as an arbitration statute or arbitration provisions in the rules of civil procedure).
3. AODRS will publish its source code.
4. AODRS will accept the following input:
   1. Parties and their status (claimant/respondent)
   2. Jurisdiction
   3. Award cap (agreed or imposed by law)
   4. Claim amount
   5. AODR-compliant claim type
   6. AODR-compliant evidence
5. AODRS will generate the following output:
   1. An arbitral award
      1. Dismissing the claim, or
      2. Awarding an amount (greater than zero and less or equal to the claim and less or equal to the award cap) to the claimant.
   2. An error message

An outline of a reference (model) implementation of the standard:

1. Only subscribers may be parties to AODR.
2. Subscribers will enter into an arbitration agreement.
   1. The agreement will bind subscribers to
      1. an AODR procedure including dispute types and
      2. AODR-compliant transaction evidence standards.
3. The implementation will provide a machine-friendly API.
4. The implementation may provide a human-friendly UI.
5. The implementation may charge subscribers a fee.
6. The implementation may use blockchain for parties’ identification and evidence authentication.
7. The implementation may convert its output to court-friendly format for award enforcement
   1. A court API (long-term—here is to hoping)
   2. A paper-based format (PDF) for service and filing (right now)

A simulation of an AODR proceeding

Example 1: sale of goods

Successful transaction:

1. Buyer requests a quote (optional).
2. Seller provides a quote (optional unless step 1 was completed).
3. Buyer sends seller a purchase order.
4. Seller accepts or rejects the purchase order (failure to complete or rejection renders the transaction non-AODR-compliant).
5. Seller delivers goods to the seller.
6. The buyer accepts or rejects the goods (failure to complete or rejection renders the transaction non-AODR-compliant).
7. The seller sends an invoice to the buyer.
8. The buyer sends a payment to the seller.

Dispute:

1. Any party fails to complete any of steps 1–7 above (except when the transaction is rendered non-AODR-compliant or when steps are optional)—AODR will dismiss the claim for payment.
2. The buyer fails to complete step 8 (AODR will generate an arbitral award for the amount in the purchase order in favour of the seller; the seller will obtain a court order or writ without notice if enforcement is necessary).

Example 2: loans

Successful transaction

1. Borrower sends a loan application to the lender.
2. The lender approves or rejects the application (failure to complete or rejection renders the transaction non-AODR-compliant).
3. The lender disburses the loan to the borrower.
4. The borrower repays the loan on the terms of the loan application (two material terms: amount and time).

Dispute:

1. Any party fails to complete any of steps 1–3 above (except when the transaction is rendered non-AODR-compliant)—AODR will dismiss the claim for payment.
2. The borrower fails to complete step 4—AODR will generate an arbitral award for the amount computed in accordance with the loan terms in favour of the lender; the lender will obtain a court order without notice if enforcement is necessary.

A draft standard for AODR-compliant evidence

1. A transaction consists of a set number of steps and parties.
2. Each party is authenticated before the transaction.
3. Each party digitally signs and publishes a record of its completion of each step to a public or private ledger (blockchain).
4. Evidence conforms with the transaction type schema (number and nature of steps).

In sum, the idea is that if transactions are standardized and their records automatically land in electronic escrow, software can resolve disputes over such transactions automatically. Software will output enforceable electronic arbitral awards saving creditors money and time. A great number of transactions are amenable to this process. All eligible contracts, from loan agreements to supply arrangements, should make AODR compliance mandatory. There is enough technology and law to support AODR now.

___________________________________

This is a series of posts that will borrow heavily from your feedback. Please leave a comment if you are interested in this subject.