Re: Side Bar Question: ISO 20022

Walter;

Thank you for the detailed response.  I backed into the credit/debit arena
from the Internet side.  For years I was frustrated with having to work
with varying ISO8583 message protocols and non TCP/IP protocols.  Drove me
nuts.  Felt like I was dealing with 'insane' points of views and
implementations for something so common to our experience that it should be
much easier.  8583 isn't that bad compared to other things and I haven't
had to work with anything in the 20022 realm and doubt I ever will.

Thank you again for helping me understand.

Stephen Cannon

On Thu, Mar 15, 2012 at 1:53 PM, Walter <walter.stanish@gmail.com> wrote:

> > 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.
>
>


-- 
Thanks
Stephen Cannon
Mobile: 727.386.6298
stephentcannon@gmail.com
<http://www.debitelite.com/>