Hacker News Reader

Comment by lelc | Hacker News Reader

If anyone from the FED is reading this I have this advice: don't use ISO20022! (I've been working on the brazilian instant payments project, known as PIX). It's an overly-complicated-try-to-solve-everything standard that promises interoperability but only delivers pain and misery. Since each country has its own standards for person and account identification, in dealing with these local realities, the ISO20022 adds quite a lot of complexity. But all this cost does not result in interoperability. In fact, each payment scheme end up with a localized version of the standard, incompatible with others. What could have been a clean API, ends up a mess.

View on HN

I actually do work at the New York Fed and saw this announcement recently myself. I was wondering about that standard and started looking at the website, but it seemed a bit light on information, which made me suspicious. At least I know my instincts may have been on the right track.

Unfortunately, I'm much too far removed to influence anything. The Federal Reserve System is massive and distributed into many large silos (Reserve Banks & The Board of Governor's) that prevent power from being too centralized in a single bank, but also make it difficult to work with anyone that's not in your bank. Interestingly, this is by design! Anyways, this work is primarily driven by the Board of Governor's and I'm at FRBNY, so I'll probably be getting most of my information from press releases like this one.

I'm also working with Brazilian instant payments schema, aka PIX. We've simply created a mapping layer to convert all ISO messaging to json.

Internally all our logic runs on json. It works because at the end of the day, payments only need a few fields to work: Source, Destination, Amount.

Quite scary to run financial transactions using an untyped format.

Everything is JSON these days, unfortunately.

You can apply schemas and force integers although. You also have typed serialization formats such as protobuf.

You'd be surprised just what kind of stuff goes through JSON to be parsed by unreliable Javascript engines 9ver software that doesn't correctly implement the JSON standard

>.<

>json

I hope you aren't using floats for cents!

Honest question. Would it differ if one used floats in json rather than floats in XML?

No it would not, but you could use decimals in xml.

Edit: looks like there is no float in xml.

Nor are there floats in JSON! Json numbers are stored in decimal with varying lengths.

Yes, but almost any standard JSON package will map a number with decimals to their internal float.

While alternative parsers exists (javascript has LosslessJSON for example), they're a pain to use.

Using strings for floats only has a tiny overhead, but it allows users to use standard JSON parsers and it signals a good practice.

If you use JSON numbers to serialize money, you create a situation where the path with the least friction is the incorrect one.

> While alternative parsers exists (javascript has LosslessJSON for example), they're a pain to use.

FWIW in Python that's as uncomplicated as

    json.loads('1.1', parse_float=decimal.Decimal)

though of course it helps tremendously that `decimal` is part of the stdlib.

Numbers in JSON are stored as strings. So as long as encoder/decoder is storing them in suitable format e.g BigDecimal no precision need be lost.

That may be technically true, but decoding sad encoding JSON without reading numbers as doubles is a special feature.

I wouldn't think so, the issue is not so much float in the storage layer (although precision in converting to and from the storage layer can make for interesting complications) it's floats in the applications layer.

what do you guys think of https://mojaloop.io/ vs ISO?

Even the BCB itself has this ISO20022-xml to simpler-schema-in-json mapping layer.

Not a good start.....

To support these goals, the service will use the widely accepted ISO 20022 standard and adopt other industry best practices, that would remove barriers to interoperability, in order to avoid unnecessary and burdensome incompatibilities, to the extent the existing private-sector service also uses publicly available, widely accepted standards.

And I got downvoted for predicting this a few weeks ago.

Not today! ISO20022 is indeed a mess

Congrats on predicting it, but if you don't have any proof, you look exactly the same as all the crazies spreading unjustified rumors.

Without proof (or at least some great reasoning), I think downvotes of "predictions" are correct.

Just need to look at all the other instances.

Incidentally, the Australian equivilant of this (NPP) is going with ISO20022.

Canada is too

What would be an alternative?

A brand new protocol.

https://xkcd.com/927/

A standard backed by the US government isn't going to be just another standard.

Yeah, there is an amazing amount of power to force adoption if the Fed tells banks, that to continue to be banks, they must adopt this data standard.

Why don't just copy what's in use in other countries? For example, sending and receiving money in the EU is pretty simple, you only need their IBAN, and maybe their name (AFAIK some countries require it). I'm not even aware of what's going on in the background, but from the user perspective its easy and free.

Well "what's going on in the background" is exactly what's being discussed here. End users will never be exposed to any of it.

No. They didn’t say build a new protocol to rule them all.

On the contrary the argument was to build a locally minimal, but sufficient, protocol that doesn’t try to compete with other locally suitable protocols.

People are taking the parent comment very seriously.

Well documented json

Any protocol with schema is better than well documented anything.

I’d pick protobuf. Or json with schema if json is preferred.

Schema works on machines, good documentation is work for humans.

But you can aut-generate the docs from code/schema!

What alternative do you suggest? Keeping in mind all the parties that will be involved, besides your project.

Create a fit to purpose, simpler, protocol using a good interface specification language (OpenAPI or protocol buffers). Maybe borrow concepts and patterns from the ISO standard, but not adopt it. It will not deliver its promise of interoperability. It might actually make it harder to interoperate with other payment schemes.

Interledger Protocol (ILP, ILPv4).

Interledger Architecture:

https://interledger.org/rfcs/0001-interledger-architecture/#... :

> For purposes of Interledger, we call all settlement systems ledgers. These can include banks, blockchains, peer-to-peer payment schemes, automated clearing house (ACH), mobile money institutions, central-bank operated real-time gross settlement (RTGS) systems, and even more.

[...]

> Interledger provides for secure payments across multiple assets on different ledgers. The architecture consists of a conceptual model for interledger payments, a mechanism for securing payments, and a suite of protocols that implement this design.

> The Interledger Protocol (ILP) is the core of the Interledger protocol suite. Colloquially, the whole Interledger stack is sometimes referred to as "ILP". Technically, however, the Interledger Protocol is only one layer in the stack.

> Interledger is not a blockchain, a token, nor a central service. Interledger is a standard way of bridging financial systems. The Interledger architecture is heavily inspired by the Internet architecture described in RFC 1122, RFC 1123 and RFC 1009.

[...]

> You can envision the Interledger as a graph where the points are individual nodes and the edges are accounts between two parties. Parties with only one account can send or receive through the party on the other side of that account. Parties with two or more accounts are connectors, who can facilitate payments to or from anyone they're connected to.

> Connectors [AKA routers] provide a service of forwarding packets and relaying money, and they take on some risk when they do so. In exchange, connectors can charge fees and derive a profit from these services. In the open network of the Interledger, connectors are expected to compete among one another to offer the best balance of speed, reliability, coverage, and cost.

ILP > Peering, Clearing and Settling: https://interledger.org/rfcs/0032-peering-clearing-settlemen...

ILP > Simple Payment Setup Protocol (SPSP): https://interledger.org/rfcs/0009-simple-payment-setup-proto...

> This document describes the Simple Payment Setup Protocol (SPSP), a basic protocol for exchanging payment information between payee and payer to facilitate payment over Interledger. SPSP uses the STREAM transport protocol for condition generation and data encoding.

> (Introduction > Motivation) STREAM does not specify how payment details, such as the ILP address or shared secret, should be exchanged between the counterparties. SPSP is a minimal protocol that uses HTTPS for communicating these details.

[...]

  GET /.well-known/pay HTTP/1.1
  Host: example.com
  Accept: application/spsp4+json,  application/spsp+json

Reply on news.ycombinator.com