- From: Walter <walter.stanish@gmail.com>
- Date: Fri, 16 Mar 2012 00:53:20 +0700
- To: opentransact@googlegroups.com
- Cc: public-webpayments@w3.org
> Guys; > > I apologize in advance if this has already been brought up. I come from > the card issuing and acquiring industry. > > Have you guys looked at what SWIFT is up to and ISO 20022 to make sure this > project is in alignment with what at least appears to be the global shift? > > ...and whether or not this project needs to address support in some way? Hi Stephen (and Pelle), While I am mostly monitoring what's going on here and have not yet had the chance to contribute or comprehend fully, I have personally reviewed every ISO 20022 change request through 2012 so can possibly comment further, with a reasonable (though still very much incomplete) understanding. Hopefully this can be helpful to both parties. OpenTransact appears to be basically a web-oriented proposal, with a very heavy emphasis on enabling B2B/B2C/C2C transactions to occur across this public infrastructure - without the procedural drawbacks of today's conventional credit card gateway and manual entry (or trusted merchant holds payment information) model. ISO20022, by contrast, is the child of historic finance industry efforts to communicate in private. Its style is less 'open and decentralized' (in the sense of "anyone connects to anyone"; generally ISO20022 is centralized network oriented - think SWIFT, credit card companies, central banks, individual banks' branch or ATM networks.) and more 'specialized' (in the sense of attempting to define many highly specific message types across numerous smaller use cases such as ATM messaging, card related messaging, various market messages, etc... certainly to the point of enumerating message types that are only relevant to very small parts of the world or the community). Whilst this is of course valuable as both an historic effort and a functional solution for those parties who have embraced it, the ISO20022 change request documents suggest systemic failures: their volume, heterogeneous style, occasional absence of downloadable copy (5-10 of them 404), and increasing trend toward statements to the effect of "if you don't give us what we want we'll just use it anyway" (ie. veiled expression of frustration toward the temporal efficiency, decision making capacity or process body surrounding ISO20022 maintenance by some of its very largest users) are worrying but not critical signs. More critical are poor extensibility (many very local changes pollute the global namespace and cause significant procedural and cognitive overheads, rather then being possible to add safely at the per-implementation/deployment level where relevant - eg. See change request #103), undeveloped poor tax/fee handling (I believe I recall requests to add at least three or four tax related fields, which were not without redundancy), indications that parts of the prior protocol were dropped without community consultation, etc. It seems pretty clear that, behind the veil, ISO20022 is perhaps a sub optimally designed protocol; skeptics might view it as something closer to a centrally choreographed collection of industry demands filtered 'best effort' through a decision making body whose total output is periodically culled for rethinking and concision (ie. 1991's ISO7775 became in 1995 the standard ISO15022 which became in 2005 or so the standard ISO20022). This is certainly one way to maintain a protocol, but very different to the way that the internet typically defines and implements protocols. The success of the TCP/IP protocol suite than underlies the internet is significant in that the whole world has seen it as the best way to solve real communications related problems. It has existed for decades with minimal core changes and wild success, even displacing massive existing investments in traditional telephony, cable television, and other major infrastructure. By contrast, *the success of ISO20022 can be viewed as practically mandated* by a combination of SWIFT, regulators and a historic lack of alternatives, with neither it nor its predecessors proving their ability to survive particularly long when applied to a truly global audience. Given this background, it is interesting to note that the cultures of these standards also parallel (or perhaps pre-empt) these differences; one is decentralized and minimalist, the other is centralized and highly prescriptive. Whilst both cultures have their own qualities, it might not be too extreme to suggest that the general trend of late (post Renaissance?) has been for decentralized alternatives to replace formerly centralized or centrally mandated systems where they are encountered. Instead of owing absolute allegiance to your lord, by pain of death, you can these days just walk across the border (or even just in to the embassy) to embrace another mode of thought. Likewise, instead of having only one practicable value store available, the local currency, you now have many: foreign currencies, various financial instruments, precious metals, etc. In summary, ISO 20022 and OpenTransact target different problem spaces. While presently only ISO 20022 is finished and globally deployed, if you believe that history repeats itself, then it appears clear that someone is going to produce something to topple centralized financial messaging standards sooner or later - hopefully something that can last longer than ten years without a rewrite, and can respond more effectively to real market changes (non ISO4217 digital currencies, mobile, mutual credit systems, etc.). Is OpenTransact going to be that single replacement? I don't know, but based upon my imperfect understanding I strongly suspect not, since its scope appears to be less broad. It could well be a piece of a multi-part replacement, though. Regards, Walter Stanish Payward, Inc.
Received on Thursday, 15 March 2012 17:53:52 UTC