If it were a single job, it would be easy, but: The Federal Reserve System has been given a dual mandate—pursuing the economic goals of maximum employment and price stability.
297 karma · joined October 16, 2020
That is a pretty bold statement to that scripting languages allow business logic to be written faster and cheaper. I think that it depends completely on the size and complexity of your business logic, and on whether you factor in the cost of maintaining that software over time.
1) Model the domain in the programming language, and store data as opaque blobs. 2) Model the domain in relational tables, and use the application logic to extract and transform the data.
On the desktop, Microsoft and C++ were already well established. In the browser, Sun did not offer a browser of their own, so Java depended on support from Netscape, Microsoft and eventually Google. Those companies all had their own technologies for browser development tools, and never tried very hard to support Java. Also Java was a little too much for many 90's era PC's connecting to the internet over dial-up connections, so it was slow.
An explanation of what happens is at initiating and receiving banks is beyond the scope of anything I want to type.
At banks with high volumes, more processing is automated (see above) for low volume banks, not so much. Payments may fall out of automated processing for several reasons like poor instructions quality (unknown account number), complex correspondent/routing requirements, sanctions screening (OFAC in the US). For high volume banks, even with high STP rates, this can mean 1,000's of payments per day.
As for why wires cost so much, the answer depends on who is paying. The most frequent users of wires often pay very little for them because bank's provide wire services as a package in exchange for holding balances with the bank. Only retail customers and small businesses pay full price ($25-40) for wire payments, and bank's charge this much because they can. Retail is such a small part of the wire payments business that if you take you business elsewhere the bank does not really care.
One last note on pricing. Most wire originate from the same set of bank customers on a regular basis, so their processing is highly automated and the bank's risk and fraud systems are trained to expect these payments. Occasional payments from retail customers probably do require manual processing more often, so a higher price is probably warranted to some extent.
The part of you post that I was primarily objecting to was that bit about this "UBS won't get $50 million added to their balance sheet because other banks don't recognize the Sberbank -> UBS transfer since it's not on SWIFT." That makes no sense. SWIFT is just messages sent between banks, other banks don't know what messages are sent between two other banks.
This is not exactly true. Chase, like many other US banks, is regulated by the Fed, and deposits at Chase are insured by the FDIC (Federal Deposit Insurance Corporation). If Chase becomes insolvent, the FDIC will take over, pay depositors up to the FDIC insured maximum, and liquidate any Chase assets. The Fed is not required to do anything in such a situation.
The Fed may choose to conjure up some new money and loan that new money to Chase, and as Chase is a systemically important bank, the Fed might well do that before the FDIC steps in, but they are not required to.
The suggested learning was that more testing should have been done, but as a solution, more testing is a cop out. A real solution is to develop code in a language that supports a robust type system, and then using that type system effectively in development.
Not an easy solution, so in the short term, we'll have more testing, and more bugs.
Historically, it has been difficult to beat monolithic kernels for performance and efficiency, and through significant effort, monolithic kernel based OS's exist that are reliable enough to be useful. However, the monolithic kernel is not the only OS architecture.
With effect from January 1, 2022, no entity in the card transaction / payment chain, other than the card issuers and / or card networks, shall store the actual card data. Any such data stored previously shall be purged.
There was a lot of interest in early days of Java and the internet in mobile code that could move between devices. It seems that interest in such systems has waned. I suppose this was more of a solution looking for a problem. However, I still think that there is potential there in some way.
I am know very little about Python, but does this mean that Python has no way to encapsulate code at a level larger than a class? Something like a package or a module. It does not seem like it should be necessary to break a system into separate services just to get encapsulation at a module of subsystem level.