Prior author of finance-related internet standards drafts here. This is quite a simplistic and Eurocentric proposal. The core design problem I see is that, in

Prior author of finance-related internet standards drafts here. This is quite a simplistic and Eurocentric proposal. The core design problem I see is that, in terms of the overall use case, it may in practice already often be the case that an existing identifier, not designed for payments, is used to identify the recipient (for example, an email address, phone number or nationally issued personal or corporate identifier) and that the actual settlement method (bank transfer, paypal, bitcoin, physical goods transfer, etc.) is not specified. However, in this design you see that the settlement method must be specified along with the recipient, which is functionally nearly equivalent to providing (http://closed-system.com/method/specific/URI http://closed-system.com/method/specific/URI) thus largely devaluing the payto:// proposal. A 'real world' use case for global payments: "I want to transfer some value over there": where there is defined, and some value is defined, but the potentially multiple means and steps to achieve the result may be many and varied and depend upon various additional criteria or preferences (cost, speed, trust, volume and asset type limitations, accounting or regulatory requirements, requirement for confirmation of delivery, error handling potential, day of week, time of day, holiday, reversibility, etc.). Additional design problems are that there is no transaction or invoice identification system specified which will deeply frustrate customer service/auditing/reconciliation, temporal limits are not possible to specify, and that the approach of shoving all required metadata for a transaction in to generic fields without specifying their formatting is going to cause havoc with all sorts of use cases particularly the disparate allowable character ranges of thousands of banks' various AML/KYC field requirements for SWIFT transfers. I also note that the proposal comes from Switzerland (home of SIX/SWIFT) and that its de-facto enforcement of ISO4217 effectively holds users of the protocol hostage to that central authority in terms of which currencies/asset types they are allowed to trade in. I would further suggest that any good faith global payment schema proposal should at least include https://en.wikipedia.org/wiki/WeChat#WeChat_Pay_digital_payment_services https://en.wikipedia.org/wiki/WeChat#WeChat_Pay_digital_paym... https://en.wikipedia.org/wiki/Alipay https://en.wikipedia.org/wiki/Alipay https://en.wikipedia.org/wiki/UnionPay https://en.wikipedia.org/wiki/UnionPay For a deeper exploration of the transaction area see the unfinished proposal IFEX @ https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco... For an alternative approach to internet based financial endpoint identification see IIBAN @ https://tools.ietf.org/html/draft-stanish-iiban-01 https://tools.ietf.org/html/draft-stanish-iiban-01 For a broader asset type identification system that does not bar innovation, see X-ISO4217-A3 @ https://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01 https://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01