Side Bar Question: ISO 20022
Stephen Cannon
Pelle Braendgaard
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
Walter
>
> 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.