Re: The path forward for Web Payments

RE: Spot exchange rates... in a way that treats precious metal certificates
and legal tender and non-legal-tender fungibles in the same way.

David, Please take a look at my message yesterday, and
http://projectmanagementhotel.com/projects/free-libre-commerce/wiki/UseCase%E2%80%93PriceIndexing
Published "spot exchange rates" constitute just one of several ways to
handle multi-currency contracts in a generic web payments system.

My most important recommendation for the W3C Web Payments Community Group
is to avoid hard-coding into the standard and into reference
implementations the "official" spot exchange rates as THE index for
variable pricing. If that's done, we will have only liberated the payments
"courier service" from credit card companies and related moneychangers, but
we will have still locked vendor-purchaser "pricing" to the speculative
forex market.

Want to see *who* that is? Look here:
http://www.euromoney.com/Article/3196124/FX-survey-2013-Results-index.html
Basically it's:
Deutsche Bank (largest for past 8 yrs)
Barclays Capital
UBS AG
Citigroup Inc.
JP Morgan
HSBC
Royal Bank of Scotland
Credit Suisse Group
Goldman Sachs
Morgan Stanley
BNP Paribas SA
Nomura Holdings Inc.
Société Générale SA

All I'm recommending is to ensure that vendors are free to choose whether
their prices shall be indexed to the speculative forex market, or to
something else, and to provide an API for those choices.

For a vendor and a purchaser to have autonomy over their transaction(s),
among other things they need to be free to (a) choose their transaction
currency(ies), and (b) negotiate their price(s). In multi-currency
contracts, the parties must see prices in two or more currencies. They may
well agree to externalize inter-currency valuation to an external third
party, or instead they can choose to "be the currency market" for the
purposes of that transaction. (Have you ever autonomously negotiated
inter-currency valuation on a streetcorner or at a hotel front desk in a
country with controlled official exchange rates?  The derogatory term is
"the black market" for currency. The respectful term is "the free market"
for currency.)

Vendors and purchasers of products and services have a different
inter-currency use case than currency speculators. Vendors and purchasers
want inter-currency price stability. Currency speculators want
inter-currency price volatility. To the extent that a vendor or a purchaser
seeks to gain an advantage through expected inter-currency price
volatility, they are to that extent forex speculators. I don't care, as
such, I'm just distinguishing the inter-currency speculation market from
the products and services market per se.

Published exchange rates amongst central bank currencies are driven by the
$5-trillion-a-day speculative forex market, and also published Bitcoin
exchange rates at Mt.Gox etc. are just as speculative. Any autonomous
community currency that is set to par against its national currency is tied
to the speculative value of that national currency. That may be good enough
for the community members since their currency's geography of use is
entirely within their national currency zone.

By freeing vendors from the requirement that credit card companies and
other oligopsonist moneychangers must handle online payments, the open
standard peer-to-peer web payments system provides a venue for vendors and
purchasers not only to manage their own money transfers, but also to "be
their own currency market" within the scope of their business, and to
decide to step outside of stormy speculative markets if they wish.

There are a few ways to accomplish this, but a way that I think has
multiple advantages is to permit vendors generally to publish fixed, OR
variable OR negotiable prices. If the vendor chooses variable, they would
need to also declare a reference against which their prices would vary.
This is useful both in single-currency and mutli-currency scenarios. For
example take a single-currency case: a chocolatier could say that the
published price of their final products, even when sold only in EUR's, will
vary with the actual prices in EURs of cacao beans and of sugar at the
port, i.e. the two highest value intermediate inputs they need to deal
with. Why vary their published price against those inputs? To protect the
chocolatier's business from manipulation like this:
http://about.bloomberglaw.com/legal-news/commodity-prices-wrong-as-often-as-27-of-time-for-traders/
 and from shocks like this:
http://uk.reuters.com/article/2013/10/18/uk-brazil-sugar-fire-idUKBRE99H0UX20131018
Meanwhile, the custom chocolate creations they offer to make, are priced
based on the requirements: "Call us for pricing".  So the clients eat both
the chocolate and the risk.

By handling the whole inter-currency valuation matter this way too, as just
one of the variable price indexing options, we can keep everything within
the realm of contract law, and steer clear of international trade law which
you get into when dealing directly with "exchange rates". Trying to come up
with some autonomous exchange rate system for both legal tender and
non-legal-tender fungibles -- beware: that's a very prickly place to be. My
strong recommendation: keep the whole thing under contracts law. Let
vendors control prices for their products and services.

So, let's say the web payments system enables vendors to publish fixed, OR
variable OR negotiable prices. And, let's say that when the variable price
option is chosen, they need to choose a pricing index from a list of
properly formatted indices. Suppose the vendor can simply choose one from a
drop-down list, as explained in my previous post:
(a) "Official" spot exchange rates base on the WM-Reuters forex index
http://www.wmcompany.com/wmr/Services/ClosingSpotRates/index.htm and
sources such as https://www.mtgox.com/
(b) The World Price Index
http://www.worldeconomics.com/WorldPriceIndex/WPI.efp
(c) Official Consumer Price Indices
http://data.worldbank.org/indicator/FP.CPI.TOTL.ZG
(d) An index linked to market capitalization  http://www.world-exchanges
.org/statistics/monthly-query-tool
(e), (f), (g), ... etc.  One of these I hope would be the Earth Reserve
Index under development. One of the options, could be "Vendor-defined", and
if some other chocolatier wants to index their prices inversely to the
Happy Planet Index, go for it. http://www.happyplanetindex.org/

Now in this approach, the vendor retains control over both their payments
courier and their effective prices.

Joseph Potvin


On Sun, Oct 27, 2013 at 5:04 AM, David Nicol <davidnicol@gmail.com> wrote:

>
> I've got two things to add
>
>
> On Tue, Oct 22, 2013 at 6:10 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:
>
>
>> External Payment Initiation - We've been talking with a few
>> organizations that do payments that would like a way to initiate a
>> payment within the browser and then hand the transaction execution off
>> to an external application. The general concept needs to be worked out,
>> and we need to find editors for this specification. If we can get
>> something together for this in the next 4 months, we stand a good chance
>> at getting a first draft ready before the Web Payments WG is chartered.
>>
>
> This feature does *not* require any browser extensions, as a
> locally-running "external application" would use the same protocols (JSONP,
> probably) as an equivalent application
> running elsewhere on the network.
>
>
>> So, what did I miss or exclude that probably should be included? There
>> is a lack of Bitcoin-related specs only because we haven't had anyone
>> from the Bitcoin community step forward and propose a set of specs to
>> take through W3C. The same applies for Ripple at this moment in time.
>>
>> Are there any specs that should be added? Should some be removed?
>> Thoughts and general debate on the direction would be appreciated at
>> this point. :)
>
>
> Spot exchange rates at vendors and at intermediaries, in a way that treats
> precious metal certificates and legal tender and non-legal-tender fungibles
> in the same way. Ripple and Bitcoin are in the third category, so are Gift
> Certificate and In-Store Credit Balances when transferrable.
>
>
>
>



<http://goo.gl/Ssp56>