[b2b] Narrowing scope: a check-like instrument (iCheck)

We've had some recent discussion here about B2B payments. These have
variously introduced other protocol stacks, technologies, and generally
tended to enlarge scope. If we're to make progress, however, it seems
important that we identify problems or use cases of narrower scope that
could be initially addressed. I have a hypothesis that a problem of such
narrower scope, but still potentially wide relevance, may be the following:
a payment message that is *payment-method-agnostic*, sent from payer to
payee, for deposit or processing via a payment method (and a corresponding
processor) that the payee selects from among those offered by the payer.
Let's call it an "iCheck", say: like a check, but with a choice of deposit
options, each with differing characteristics of payment timing, processing
speed and cost. Note that the "processing speed" / "payment timing"
distinction refers to possible financing elements that might be bundled
with one or other payment method. Of course, I'm suggesting this idea here
with the thought that an ILP-based payment option might be supported. That
said, in the relatively near-term, echeck, ACH and card options would
likely be bigger factors in making this useful to real-world business
users. (For cross-border payments, these might include perhaps Letters of
Credit, SWIFT's Bank Payment Obligation or other instruments).

Despite the narrowed scope, indeed partly because of it, I suspect that
such a payment instrument could catalyze the emergence of the "Internet of
Payments" (IoP). This IoP notion is closely aligned with the "Internet of
Value" notion around ILP. But it's not identical, focused as it is on the
application / data / process layer - to some extent independent of the
underlying settlement rails. I don't want to get into here the bigger
picture considerations of how the Internet of Payments might emerge at
scale. If you're interested, here's a white paper on "How to Build the
Internet of Payments
<https://drive.google.com/open?id=0BwAEzaYR8B-MS0pyTnlXbUNVYkU>". See below
for some more details of the advantages I see for such a payment instrument
- and how this might work in practice from an end-user and process
flow perspective.

I'd welcome comments and feedback from any perspective. Most practically
though perhaps, would be thoughts as to what would be entailed for an
ILP-based implementation here, on both the payer and payee sides.

Best regards,
Roger


Some key potential advantages to such a payment instrument:

   1. it eliminates, in large part, the chicken-and-egg issues that ILP
   faces, like any new network technology, by decoupling payer and payee
   adoption
   2. it aligns with current business check payment processes (especially
   in the US)
   3. it requires no payee pre-enrollment to send payment (in most cases)
   4. it allows payees to process the payment through their existing
   processes and providers - no change required (perhaps at higher cost if
   over legacy rails)
   5. it provides payees the option of getting paid sooner and/or at lower
   cost, to the extent they select a payment method / processor that supports
   those options
   6. it creates a viral channel for marketing / distributing payment
   processing services (in the payee's local market) that support the
   better/faster/cheaper options
   7. it creates, via the viral channel, a market mechanism for driving
   banks and other incumbent providers to support the better/faster/cheaper
   options
   8. it supports an ISO 20022 remittance data payload, allowing
   straight-through-processing integration with payee software systems
   (existing... or new)

>From an end-user / process flow perspective, an implementation might look
like this (somewhat simplified):

   1. A corporate payer uploads to their bank or payments provider a
   Payment Instruction File (much as most do today). This PIF includes details
   of payees, payment amounts, email address or other identity / routing
   information, and remittance detail. The payment method might be specified
   for a particular payee - but in general, all alternate payment methods
   supported by the payer and their provider might be offered.
   2. For payees with whom no specific e-payment channel was previously
   configured, the baseline payment mechanism (at least domestically) might be
   an electronic check facsimile, for deposit through standard existing
   channels / processes (remote deposit capture etc). Different providers
   might favor / promote different payment methods (e.g. card payment for
   card-oriented providers).
   3. Alternate electronic deposit / processing options might be offered
   via either human- or machine-oriented interfaces:
      1. Human: a web link or button, inviting payees to identify their
      company, test for an existing payment channel/account, or if none, to
      provision a new one
      2. Machine: an equivalent URI pointer, embedded perhaps as an S/MIME
      attachment via some envelope protocol, enabling selection of the payment
      method to be used, from those offered, and configuration of a secure
      channel for delivery of payment + remittance information, on
that occasion
      and subsequently. (More complex handshake / negotiation protocols would
      likely be needed over time).
   4. After a first interaction / payment flowed to a payee through such an
   email process, subsequent payments from the same or other payers might do
   the same - or arrive through a purely machine-to-machine process, if one
   was activated and authorized by the payee to act as their proxy. (Not
   incidentally, the initial payment interaction with a payee might include
   their enrollment into some Discovery mechanism for future payments, such a
   mechanism including a pointer to a "Metadata Service" for their automated
   payment proxy).