Re: Interesting report from World Economic Forum on future of financial services

RE: "and would love to hear your thoughts on it"

Like the others I also find this report to very useful, especially in
helping to illustrate the high-level architectures of many of the key
processes.

Following are some elements that seem to be missing. I'm c.c.ing Jesse
McWaters of the World Economic Forum:

1. Transactions are described as initated by either the "recipient bank" or
by the "sender". (For example, see pg 47, "Key Characteristics" under the
Value Chain diagrams.) It seems to me that in all three scenarios the
transaction should be initiated *from outside* the financial services
domain. This is acknowledged for the second and third columns (Sender;
Recipient), but not in the first one. And the way that any transactions
would be initiated is through the acceptance by both parties of the
contract agreement, which is normally instantiated in e-commerce via a
message sent from an e-invoice once the second of the two parties agrees
(which might be the payer or the payee). The invoice (the contract) is
'owned' by both the sender and recipient of the payment, so I reckon it's
better to say that transaction is initiated by "an event" in the e-invoice,
which signals the acceptance of a contact. In the first column, perhaps the
e-invoice-generated message would always go first to the *payer*'s
depository managed by a bank, but I'm not sure -- maybe the payee's bank
could come first in some scenarios (even if less common).  If others think
I'm correct in these comments, I'll be happy to collaborate in adapting
some adjusted graphics from these three columns.

2. Generally I think what's missing in these representations is to
distinguish the persons (eg Sender; Recipient), from the e-invoice (the
word "invoice" does not appear once in the report), versus the
e-depositories of the parties.

3. Two other words that don't appear in this report are "token" and
"registry". This is surprising because a primary source such as UNCITRAL
recognizes two classes of monetary instantiation. Therefore one may expect
there there must be two very types of repositories that function to store
money:

   - “Registry-Based” (scalar values in a ledger)
      - Each record (account) in the registry has a unique owner (perhaps
      with the ability to authorize access by others);
      - Transfer of rights is accomplished via balanced arithmetic changes
      to scalar values in the account: +1 here, -1 there;
      - Control is accomplished via verifiable unique owner identities &
      credentials;
   - “Token-Based” (unique artifacts in a depository)
      - Each token is an original and unique record;
      - Transfer of rights is accomplished through transfer of control over
      the token record itself (similar to paper-based or coin-based);
      - Control is accomplished via the verifiable unique tokens.

4. This broad financial services overview seems to be nicely complementary
to the so-called omnichannel perspective. The two go hand-in-hand. A couple
of interesting items about omnichannel are:

   -
   http://www.forbes.com/sites/danielnewman/2014/07/22/the-omni-channel-experience-marketing-meets-ubiquity/
   - http://www.vendornet.com/marketing/OMSwhitepaper.pdf

Regards,

Joseph Potvin
For DataKinetics http://www.dkl.com
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Fri, Jul 3, 2015 at 12:14 AM, Adler, Patrick <patrick.adler@chi.frb.org>
wrote:

> All,
>
> I recently came across the attached report in some of my work and thought
> that it would provide quite a lot of value to the broader Web Payments
> Interest Group.
>
> I hope you find the report to be as useful, and would love to hear your
> thoughts on it.
>
> Best regards,
>
> Pat
>
>
>
> This e-mail message, including attachments, is for the sole use of the
> intended recipient(s) and may contain confidential or proprietary
> information.  If you are not the intended recipient, immediately contact
> the sender by reply e-mail and destroy all copies of the original message.
>