Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ISO 8583: The language of credit cards

increase.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: ISO 8583: The language of credit cards

#71

Post by lxgr »

david-gpu wrote: post #58
lxgr wrote: post #14

Earlier quoted context omitted.

> Many low level things are basically packed C-structs with this type of protocol. Not really: C structs notably don't have variable-length fields, but ISO 8583 very much does. To add insult to injury, it does not offer a standard way to determine field lengths. This means that in order to ignore a given field, you'll need to be able to parse it (at least at the highest level)! Even ASN.1, not exactly the easiest for…

> Not really: C structs notably don't have variable-length fields Feast your eyes: C99 introduced an ~~abomination~~ feature called flexible array members (FAM), which allows the last member of a struct to be a variable length array. If you want to ~~gouge you eyes~~ learn more, see section 6.7.2.1.16 [0]. > To add insult to injury, it does not offer a standard way to determine field lengths That's awful. You can sor…

> [...] feature called flexible array members (FAM), which allows the last member of a struct to be a variable length array.

Oh, ISO 8583 has these too!

Sometimes they're even combined with the "feature" described in the article where there's a variable number of fixed-length elements, except for the last element, which is a variable-length string (or sometimes the last field type repeated n times). That's always "fun" to work with.

ISO 8583 really is a living museum of all ideas people had about binary encoding in the last half century or so.

Re: ISO 8583: The language of credit cards

#72

Post by roordan »

An interesting side effect of this low-level bit mapping is that various banks authorization logics can be manipulated to increase auth rates by subtle bit flipping across various fields.

All the big fintech companies have ML running over changes to identify what results in the highest auth rates on a per bin basis.

Re: ISO 8583: The language of credit cards

#73

Post by _blk »

lxgr wrote: post #21
ocf wrote: post #20

Neither Visa nor Mastercard really implement ISO 8583 a standardized way. Which means they each issue many thousands of pages of documentation covering not only which of the standard fields they use and how, but also how they cram their proprietary data into the messages. Most card management/issuance platforms do a decent job of abstracting this away though. Transition to ISO 20022 would be a positive improvement, b…

The large card networks have so many proprietary behaviors and extensions that I really doubt whether any common standard would even make sense at this point. And if you look at how "modern" ISO 8583 is evolving, almost all changes and extensions are already happening in TLV-like subfields (where a new field unexpectedly appearing doesn't make existing parsers explode spectacularly), and the top-level structure is es…

You're right but that's because it's already come to this. Would it have been that hard to say: these are the standardized fields usable only in accordance with the standards and these are the custom fields for your own bs.

Re: ISO 8583: The language of credit cards

#74

Post by mainde »

roordan wrote: post #72

An interesting side effect of this low-level bit mapping is that various banks authorization logics can be manipulated to increase auth rates by subtle bit flipping across various fields. All the big fintech companies have ML running over changes to identify what results in the highest auth rates on a per bin basis.

I would be very surprised if bit flipping and ML were really used here, do you have any source?

While for sure there's a lot of signal and value in monitoring auth rates per BIN per payload, flipping bits can be extremely disruptive and counterproductive. From doing the wrong operation to being fined by the schemes, it's a lot of risk for not a lot of gain when these fields can be tuned ad-hoc for the few card issuers that deviate from the standard/norm.

Re: ISO 8583: The language of credit cards

#75

Post by lxgr »

cess11 wrote: post #67
CamouflagedKiwi wrote: post #65

Earlier quoted context omitted.

This is not the case for card networks. I know of no plan for Visa or Mastercard to move to ISO20022 and even if so I am certain it will not be complete within a year from now. In fact, if they announced they were starting a migration like that, I would be dubious if it could be completed within 10 years, there are so many systems out there that would have to change. On many other payment systems, yes, ISO20022 is or…

The planning stage is history. https://usa.visa.com/content/dam/VCOM/global/ms/documents/ve... https://usa.visa.com/content/dam/VCOM/regional/na/us/sites/d... Mastercard uses data sucking nag screens, but I don't think you actually need to read the papers to get the point: https://b2b.mastercard.com/news-and-insights/payments-modern... https://b2b.mastercard.com/news-and-insights/report/iso-2002... In 2018 SWIFT deci…

Why would it matter to Visa and Mastercard what SWIFT and India (The central bank? The entire country?) are doing?

They run their own networks and everybody that wants to connect to them has to speak their protocols (which are completely custom btw; it’s out of the question to just swap out one for the other!)

> get schema files and punch your programming button and generate a lot of the necessary code and then do the plumbing and call it a day

Absolutely not. Parsing ISO 8583 is maybe 5% of the complexity of card processing (and that’s being generous). Sorry, but you seem to have absolutely no understanding of an industry you are making confident statements about.

Re: ISO 8583: The language of credit cards

#76

Post by lxgr »

cess11 wrote: post #57
ocf wrote: post #20

Neither Visa nor Mastercard really implement ISO 8583 a standardized way. Which means they each issue many thousands of pages of documentation covering not only which of the standard fields they use and how, but also how they cram their proprietary data into the messages. Most card management/issuance platforms do a decent job of abstracting this away though. Transition to ISO 20022 would be a positive improvement, b…

ISO 20022 roll-out is well underway. Unless the US decides to extend it's war on the world to the rest of G20 the plan is to be done a year from now, and if I'm not mistaken the US is a member of the PEPPOL society already. It's the lingua franca of european banks and has been for some time. Back in 2018 when I built a piece of financial software I talked ISO 20022 with a swedish bank in Luxembourg.

Sorry to be so direct, but you don’t seem to have any idea what you are talking about in this context.

Banks and payment card processing (which is what TFA is about) are basically two different worlds. One switching to a new data interchange format has essentially no consequences to the other.

While I could imagine Visa and Mastercard offering an ISO 20022 interface for new integrations, I’m willing to bet on the majority of volume staying on ISO 8583 for this decade and probably well into the next. They most certainly won’t force anyone to migrate either.

Re: ISO 8583: The language of credit cards

#77

Post by cess11 »

lxgr wrote: post #75
cess11 wrote: post #67

Earlier quoted context omitted.

The planning stage is history. https://usa.visa.com/content/dam/VCOM/global/ms/documents/ve... https://usa.visa.com/content/dam/VCOM/regional/na/us/sites/d... Mastercard uses data sucking nag screens, but I don't think you actually need to read the papers to get the point: https://b2b.mastercard.com/news-and-insights/payments-modern... https://b2b.mastercard.com/news-and-insights/report/iso-2002... In 2018 SWIFT deci…

Why would it matter to Visa and Mastercard what SWIFT and India (The central bank? The entire country?) are doing? They run their own networks and everybody that wants to connect to them has to speak their protocols (which are completely custom btw; it’s out of the question to just swap out one for the other!) > get schema files and punch your programming button and generate a lot of the necessary code and then do th…

Because they interact with banks and banks interact with them. If they refuse to support the protocols the banks use, what happens?

Sure, there's 3DS and blah blah blah, so what? 8583 is getting replaced and implementing 20022 is a breeze compared to 8583 for the specific reason I mentioned.

Re: ISO 8583: The language of credit cards

#78

Post by cess11 »

lxgr wrote: post #76
cess11 wrote: post #57

Earlier quoted context omitted.

ISO 20022 roll-out is well underway. Unless the US decides to extend it's war on the world to the rest of G20 the plan is to be done a year from now, and if I'm not mistaken the US is a member of the PEPPOL society already. It's the lingua franca of european banks and has been for some time. Back in 2018 when I built a piece of financial software I talked ISO 20022 with a swedish bank in Luxembourg.

Sorry to be so direct, but you don’t seem to have any idea what you are talking about in this context. Banks and payment card processing (which is what TFA is about) are basically two different worlds. One switching to a new data interchange format has essentially no consequences to the other. While I could imagine Visa and Mastercard offering an ISO 20022 interface for new integrations , I’m willing to bet on the ma…

You don't have to imagine, just go read what the payment processing services publish and promote.

ISO 8583 is a massive liability, just an insane amount of technical debt and nasty workarounds that harms interoperability, i.e. profits. This is why both banks and the payment sector communicate so aggressively on this issue.

Re: ISO 8583: The language of credit cards

#79

Post by bokohut »

Copyrighted wrote: post #61
bokohut wrote: post #6

A lot of payments chatter on here recently and patio11 throwing out some great content as well. May I ask where this pretty visual explanation website was 25 years ago? ;) Oh the woes of programming ISO8583 as I see another commented on EBCDIC which adds in a whole other level of mind numbing when passing between the endians. It was a fun experience however back in the early 2000s when I worked in isolation with Disc…

Painful memories of when you tell brands your data is coming in as ASCII and they have it as EBCDIC.

I referred to it as "the woes" but yes I agree with your choice of words as well. As an experienced technology builder I generalize the struggles I vividly recall and it often involves parties not doing the real work and therefore they lack the comprehension of the details that are all that truly matters. This applies to a lot of things today, tech included, where most have no idea how anything works and the solution typically boils down to, did you power cycle it?

Re: ISO 8583: The language of credit cards

#80

Post by CamouflagedKiwi »

cess11 wrote: post #67
CamouflagedKiwi wrote: post #65

Earlier quoted context omitted.

This is not the case for card networks. I know of no plan for Visa or Mastercard to move to ISO20022 and even if so I am certain it will not be complete within a year from now. In fact, if they announced they were starting a migration like that, I would be dubious if it could be completed within 10 years, there are so many systems out there that would have to change. On many other payment systems, yes, ISO20022 is or…

The planning stage is history. https://usa.visa.com/content/dam/VCOM/global/ms/documents/ve... https://usa.visa.com/content/dam/VCOM/regional/na/us/sites/d... Mastercard uses data sucking nag screens, but I don't think you actually need to read the papers to get the point: https://b2b.mastercard.com/news-and-insights/payments-modern... https://b2b.mastercard.com/news-and-insights/report/iso-2002... In 2018 SWIFT deci…

Those papers are not concrete plans to move their core processing network to ISO20022. The first one is just talking about 20022 in general, the second one refers to Visa DPS which is effectively a wrapper over their EAS which does speak 20022, but their core comms are still 8583.

I'm sure that Visa and Mastercard are very aware of 20022, but being aware of it isn't the same as having a concrete plan to move - actually moving _everything_ would take a very long time, there are so many card issuers & acquirers out there with old systems plugged into Visa and Mastercard that would have to be replaced.

FYI I actually built a cloud based issuer processor connected to one of them within the last couple of years - that was 8583 and there was no option for it to be 20022. We would 100% have taken it if it were an option.

> you get schema files and punch your programming button and generate a lot of the necessary code and then do the plumbing and call it a day.

I think that's pretty naive in terms of what parts you have to do in order to process card payments. Okay, yes, parsing messages is easier, you still have to deal with HSMs and all the crypto stuff, PCI compliance, all the logic for the various message types, scheme compliance, then the long tail where reality diverges from the spec (basically acquirers will send you any old absolute nonsense and you'll have to somehow figure it out otherwise your customers' card payments get rejected).

Post reply on HN