- From: Roger Bass <roger@traxiant.com>
- Date: Tue, 29 Mar 2016 11:42:56 -0700
- To: Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CA+nC-Xs=zHkZpUKTRL3X1-kWo4i3yGDmZYJd0U25LSH_5P1gAg@mail.gmail.com>
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).
Received on Tuesday, 29 March 2016 18:44:04 UTC