While I do appreciate the dedollarization debate, Yves Smith raises some good points about how difficult it would be, and why it’s not likely any time soon. This also dovetails into a discussion of banking infrastructure and how, for all intents and purposes, only a planned economy can effectively work nowadays. Some interesting bits:

Now why is a new currency such an uphill climb? Let’s start with two reasons (trust me, there are others). For any currency regime to operate, you need laws, institutions, regulations. Crypto users wound up trying to build bit by bit the key elements of a banking system, like custodians, and those still wound up relying on existing legal regimes (the agreement with the custodian said which law governed the agreement). Similarly, when the 11 year project to launch the Euro started, Europe had had a legal regime, with the European Court of Justice at its apex, for 40 years.

So pray tell…whose law and courts would govern a BRICS currency? You know no BRICS member will be happy to have their use of a BRICS currency subject to the jurisdiction of another BRICS member. But how long would it take to set up a free-standing court/adjudication system, and all the necessary laws? Oh, and then even if that were not a massive and fraught process, all of the BRICS members opting in would wind up having to agree that their court systems were subordinate to this new BRICS currency regime. How easy will that be to solve conflicts with regular commercial lows of these countries? […]

A second problem is all the coding. It’s remarkable how just about everyone is insensitive to how miraculous the operational side of banking is. You get your bloody bank and credit card statements every month, on time, with all those transactions listed tidily and totaled up correctly, from geographically dispersed merchants. And they are never inaccurate. There may be fraud or fees you think are wrong, but you don’t worry that your credit card statement says you spent $110.57 at Home Depot when the charge was actually $35.33, or that your neighbor’s purchases wound up on your account. And mind you, any bank or card processor is handling a simply ginormous number of transactions.

And the most staggering bit to me: given the immense amount of work needed to do any significant IT production,

According to the Standish Group’s Annual CHAOS 2020 report, 66% of technology projects (based on the analysis of 50,000 projects globally) end in partial or total failure. While larger projects are more prone to encountering challenges or failing altogether, even the smallest software projects fail one in ten times. Large projects are successful less than 10% of the time.

Standish also found that 31% of US IT projects were canceled outright and the performance of 53% ‘was so worrying that they were challenged.’

Research from McKinsey in 2020 found that 17% of large IT projects go so badly, they threaten the very existence of the company.

On a comment Yves expands on the issue, specifically on the matter of Banks’ mainframe infrastructure:

Sorry, the post is correct. Banks run COBOL.

- There are 220 billion lines of COBOL code still in use today.
- COBOL is the foundation of 43 percent of all banking systems.
- Systems powered by COBOL handle $3 trillion of daily commerce.
- COBOL handles 95 percent of all ATM card-swipes.
- COBOL makes 80 percent of all in-person credit card transactions possible

Banks have made very little headway in migrating off legacy systems. Aside from the fact that this is precisely the sort of large IT project that prototypically fails, insiders have guesstimated that the other reason it does not get done is that it would require on the order of all of a bank’s operating profit for three years. Better to use duct tape and baling wire and hope things will behave long enough so as to be someone else’s problem. […]

The banking industry relies heavily on computer systems to manage transactions, customer data, and other critical functions. Many of these systems were built using the COBOL programming language, which was popular in the 1960s and 1970s. As newer programming languages and technologies have emerged, the banking industry has struggled to keep up with the pace of change.

One challenge the banking industry has faced is the difficulty of migrating away from COBOL. COBOL code is often deeply embedded in legacy systems, making it difficult to replace or update without disrupting existing operations. This has led to a situation where many banks are still using COBOL-based systems that are decades old.

The complexity creep of IT infrastructure means pretty much only a planned economy would be capable of marshaling the resources and the coordination needed to overcome COBOL hell. Highly recommend folks to check the whole piece out.

  • Black AOC@lemmygrad.ml
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    I mean, if the legacy of widespread Hapsburgism could pull it off w/rt the Euro, I’ve got faith in the BRICS collective to eventually wrangle it. I don’t envy ANYONE programming in COBOL, though; I’d sooner run a railroad tie through my own skull than write in that language.

  • libscratcher@lemmygrad.ml
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    I don’t see how an argument against US tech startups and an argument against tech debt in 50 year old bank computer systems are both supposed to apply to the same institution. This really feels more like an investigation of every rhetorical argument that could be made against a hypothetical brics bank rather than a real one. Supported by the fact that they seem to think the difficulty in coding a bank system is making sure the ledger doesn’t “misread” entries - this is a difficult problem for humans but not computers, and it doesn’t get harder whether you have 1000 statements or 1 million.