However, there might be an easier way to integrate ISO 20022 compliance. Is it possible to leverage existing technology XRP ledger / XLM ledger into JAM or as a system chain once JAM releases. Instead of building ISO 20022 compliance from scratch for PolkadotSDK (think it should still be done for smart contract and software reasons), is Polkadot able to leverage the open source non patented parts of XRP / XLM. Both are coded in C++, which can compile to RISC-V. Also, because XRP / XLM runs on minimal number of nodes, cost of architecture is reasonably low.
I understand I am out of scope of your post. However, I am trying to understand the title. One of the things I used QA ISO 8583 (reference - ISO 8583 - Wikipedia ) Is this in the same ballpark as your title? Also what area of the world is this compliance in reference to? Thanks!
ISO 20022 is the new compliance standard used for international payments. It is being adopted by SWIFT and thus all international payments for the west and any country that does business with the west. There is a multi-year migration ongoing across the world right now. Basically every bank will be using this new payment standard. XRP / XLM are ISO 20022 compliant based systems. So if Polkadot wants to integrate with the banking industry then it needs to be ISO 20022 compliant. This is not to say that Polkadot as a whole needs to be compliant but at least the portion that it is integrated with. I believe a project is trying to see what is needed to make PolkadotSDK compliant with ISO 20022; however, a potential easier route is to re-purpose existing tech (XRP / XLM ledger) as a system chain or maybe as a service (not sure if this would work) within JAM.
Great to hear we have both ISO20022 and ISO8583 interest and experience in the house!
I think taking an existing solution and getting it to run on Polkadot (whether chain/Plaza/JAM) infra is a pretty great idea (though I’m not personally familiar with these standards or whether or not this implementation method may work).
You may know this already, but the W3F has RFPs for both:
It would be great to start a conversation with W3F to see what they think of this approach, as it may be fundable if it’s something you’re interested to pursue.
The official channel to talk to the W3F about grants is on Matrix here:
Of course, if it is not just a technical implementation thing, and there is some licensing or a partnership needed to use the XRM/XLM solution, then there could either be some kind of partnership or licensing agreement that is facilitated by PCF or the treasury.
Hey @Barakion, thanks for your post. Trying to understand a little bit better where you are coming from, could you share some more details of which specific parts of the Ripple/Stellar codebases you would like to reuse and in what way?
If you are interested in my view of the ISO20022 integration problem, I just published an article about the topic researching other blockchain’s approaches, outlining challenges and opportunities as well as technical solutions when trying to bridge the gap between a decentralized system and a messaging protocol designed to be used by trusted entities.
Having read the Grey paper and thought through CoreJAM, the proposed system is effectively running a virtualized environment. You have the underlying OS, unified database (blockchain), and then effectively different services sitting on top (I kind of like to think of these as additional operating systems in a virtualized environment for simplicity purposes; I use the term operating systems since most people think of smart contracts when you say applications). I recognize this is an overly simplistic description. The parachain service will be effectively one of many potential operating systems.
I do not claim to be an expert in ISO 20022 but to my knowledge there really is no way to be both decentralized and ISO 20022 compliant (and compliant with various national laws). The standards effectively make those mutually exclusive. If you look at something like XRP / XLM ledgers they can effectively choose who the validators are for any transaction since you don’t have to run the default nodes. In the US for example, I believe banks are mandated by law to use entirely US infrastructure top to bottom in their financial dealings. That is why Avalanche allows it subnets to pick the validators. Obviously this comes at the cost of decentralization.
With that said, doesn’t mean that Polkadot can’t implement. I would imagine that it is possible to run XLM in its entirety as a service on top of CoreJAM. XLM is coded in C++ and C++ compiles to RISC-V. One could then transact on a Polkadot XLM version in a compliant manner and then bridge Polkadot XLM with Polkadot Parachain service.
Thanks for the clarifications. I would like to follow up with the following questions/comments:
How would running XLM inside of Polkadot solve the incomatibility problem betwen ISO20022 and decentralization?
From what I undersood in your previous post, you are suggesting that this solution would simplify things. Now running an entire node of another Blockchain (Stellar in your example) seems like a lot of overhead to me and seems to rather complicate than simplify things. What are your thoughts on this?
My research shows that Stellar and basically all other blockchains claiming to be compliant with ISO20022 do not achieve this on the protocol level. How would running Stellar inside JAM help with ISO20022 compatibility? Can you point to some code that you would like to reuse for this?
It wouldn’t solve the incompatibility problem in the direct sense. It would simply allow the protocol to exist within corejam. One service like parachain service could be decentralized while the XLM (or equivalent service) would ISO compliant.
You wouldn’t need to run another node based on my understanding. XLM or a version of it would simply exist as a service just like parachain services would. Also, XLM and XRP run relatively fewer nodes so overhead is the smallest in the entire industry. Unless my understanding is wrong here, CoreJam’s genius (or at least one of them) is that it could copy entire protocols and incorporate within CoreJAM as a service. This is what makes it future proof in many ways.
Protocol level would not make something ISO compliant by itself. Would need all functionality top to bottom to be built with in mind.