The report doesn't say that because it's just reporting the facts not drawing conclusions. In my opinion, if a catastrophic failure happens that is a maintenance failure. Either the inspections failed to notice the fatigue or the inspection guidelines were too optimistic.
When did you last try it? The scenery and GPS/FMC has come a long way in the last 20 years I've been an X-Plane casual, but not so sure how much of that was in the last few.
I’m comparing X-Plane 12 to MSFS 24. MSFS 24 is a great aid and near picture perfect when preflying real world routes, with 3D buildings and everything, and the latest G1000 implementation is pretty complete too. But X-Plane still wins on physics realism and systems fidelity. I’d be happy if there was a way to combine the strengths of the two in one simulator somehow..
I don’t know much about MSFS plugin system so I don’t know if this is possible but you can easily extract data from X-Plane and then send over to MSFS. So that you use XP as physic and model engine, only MSFS as out-the-window view.
Basic things like latitude/longitude/altitude/heading should be straightforward. But then you might have problems with mismatch scenery, like missing airports/runway, different terrain heights, etc. And then the weather synchronization is another can of worms. Matching what you see with the physic model can be challenging.
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, but I don't think it will ever meet the required ROI threshold (globally) for that to happen.
Can attest, having searched through literally thousands of pages of documentation in an attempt to attribute the payment processing switch vendor when analysing the ATM jackpotting malware ‘fast cash for Linux’[1]. The best I could do was determine the currency used for the fraudulent transactions, which may imply the country of the target financial institution.
Would be curious if anyone else has further insights.
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 essentially irrelevant.
Of course, it's a significant hurdle to newcomers to get familiar with that outer layer, but I don't get the sense that catering to these is a particular focus by either network. ISO 8583 is also a great moat (one of many in the industry, really) for existing processors, which have no buy-in to switch to a new standard and the networks need to at least somewhat keep happy.
I thought that chip-in EMV was bad until I saw some of the stuff coming out of Discover cards for contactless EMV. Buying a test card set from somewhere like B2 Systems was very beneficial even just integrating an EMV reader from a hardware device to a payment processor.
In this world and age of AI, having this kind of inside knowledge that is scattered, usually behind paywall and nda, and always to be updated, is a real advantage.
Because no LLM will be able to replace you for quite a while.
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.
I don't know the current state of affairs. Last time I worked on ISO20022 (almost 10 years ago), our system were doing a 1-to-1 mapping from ISO8583, keeping every bit of unmaintable shit one could imagine
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.
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 is becoming the lingua franca - e.g. FedWire is going to move next year.
In 2018 SWIFT decided to migrate. Do you seriously believe that VISA and Mastercard did not notice this when it happened? Do you think they've been watching India adopt ISO 20022 for years and not acted upon it?
Edit:
The reason adoption is fast when the devs finally can get to work is that it's XML, 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.
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).
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.
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.
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.
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.
Having been involved in several ISO8583 implementations/integrations, it's really quite wild how different each one was in both structure and required content from one another.
Where does this report say proper maintenance would have prevented the incident?