I think that most other people would as well. Unfortunately, there are enough people willing to take advantage of that good will that you are a fool if you are not somewhat suspicious.
What surprised me most about the story is that despite a very unusual pattern of transactions for a business banking account at a local branch, the OP only received occasional calls from the local branch banker. I would have expected at least one call from the bank's compliance department inquiring about the source of the funds, and requesting more information about the nature of the OP's business. Bank's are legally required to know their customers and to report potentially illegal activity. This account clearly did not go unnoticed.
I have received such a call from Chase only once in my 35 adult years, and it was triggered by a deposit much smaller than 35M.
I believe that SVB and Signature have total depositor liabilities of 300B. They also have assets that are worth a significant portion of that. Only the difference needs to be covered by the FDIC assessment. Depending on what happens in between now and when that assets are sold, it is possible that the assets end up being worth more than liabilities, and no FDIC assessment is needed.
I agree that the lessons learned is weak. The solution to a systemic failure like this can not be that everyone involved should try harder and be more careful. A solution is needed that addresses the weakness of the system.
How about a solution where the approvers need to forfeit a significant amount into escrow accounts to cover losses and receive a portion of the payout for their efforts and investment. Any payout would be systemically limited to the total amount held in escrow.
Writing this I realize that this perfectly describes a traditional financial institution. Not such a radically new idea.
I was thinking the same thing, which leads me to say "This is where I came in." That is to say, I have seen what happens next. Maybe it time for retirement.
I have worked on a system that took exaclty this approach for ~17 years. The database was Oracle, at the time we started 'SKIP LOCKED' was not even a documented feature of the Oracle DBMS. It is now. The approach worked quite well for us and happily working today at several large banks. Also, Oracle sells what I think they call AMQ (Advanced Message Queing) that provides a messaging API but uses the DBMS for storage. No idea how it performs relative to dedicated persistent messaging solutions, but I would guess that it probably good enough for many workloads.
XA scales well enough for many workloads. I believe that too many developers discard solutions like XA because it "scales quite poorly" without doing serious analysis of how much scalability they are likely to need and whether XA scales well enough to support it. On the flip side I believe that too many developers underestimate the complexity of managing state and failure in distributed systems.
This is a little off topic, but related. Does anyone know of any tools that would allow information about the size and shape of expected data to be provided along with a database schema so that developers could get instant feedback if queries were likely to perform poorly when run against production data sets. Or to perform poorly when a database grows to beyond a certain size. I have seen many instances of SQL going into production databases that works well for a while, but gets much slower as the database grows.
I can think of at least six possible answers based on these questions:
1. Does largest mean dollar amount, or number of investments?
2. Would number of investments count companies invested in or funding rounds invested in?
3. Does largest mean the largest total dollar amount invested in 2022, or does it mean larges dollar amount of new investment in 2022?
It looks like ChatGPT chose the query to mean the investors with the largest dollar amount of new investment in 2022.
When you expand your natural language query to clarify all of these ambiguities, how far away are you from a SQL query? I am not sure, but I think that you are getting pretty close.
I stand corrected. However, I don't believe that the class source file needs to be in a directory (or hierarchy of directories) that matches the package name. Many IDE's enforce this as well, which I believe is not correct.
Yes, commonly used ClassLoaders do care about file names and directories. The Java compiler javac does not. The javac compiler compiles compilation units which are generally files, but name does not matter.
More importantly is what functional languages leave out or restrict. Imperative languages can add functional language features, but functional purity is not enforced, the full benefit of functional programming is not realized.
There was no .NET in the 90's. It was Java vs. ActiveX vs. Flash. I agree that Java support in browsers was never as good as it could have been. Sun never had direct control over a mainstream browser, and the companies that did each had other technologies that they preferred (Microsoft - ActiveX, Netscape - Javascript).
That is true, so the library should throw the checked exception, and if the caller has no way to handle it, it should wrap the checked exception in an unchecked exception and throw the unchecked exception. Not too hard, and library clients that can handle some checked exceptions will be able to.
I hate libraries that only throw unchecked exceptions. It seems easier initially, but makes writing correct code more difficult.
I agree. When Paypal was founded, there was amazement within the industry that they were able to run a money transfer service without being completely overrun by fraud. I was told that Paypal's real secret sauce was their fraud detection algorithms. It was those algorithms that created a product that others could not easily duplicate. Perhaps the fraudsters are catching up with Paypal and their algorithms, and as a result, Paypal needs to block more and more legitimate businesses that they are unable to distinguish from fraudulent businesses.
This problem does not seem unique to railroads. Any business that depends on human labor to deliver a service would have this problem. Airlines, restaurants, theatre companies. The way to deal with this is to have excess labor available (slack in the system). Are railroad profit margins so small that paying for excess labor will bankrupt them? Maybe labor in the railroad industry is so highly regulated that labor flexibility very expensive to maintain. Railroad pensions are the only private pensions that I know of that are specifically called out in IRS tax forms. That has always seemed odd to me, and is probably some indication of how tightly regulated labor in the railroad business is.
Not sure if NYS generates 70% of its electricity from hydro, but is possible that 70% of the electricity that NYS consumes comes from hydro. I believe that NYS imports a lot of electricity from Canada where it is generated from hydro.
Most financial companies have large balance sheets, a small amount of equity that is highly leveraged, and asset values based on many assumptions. If the assumptions change, a business can go from everything is great to insolvent really fast. That is why such businesses are highly regulated. With crypto we see why this regulation is so important.
Not sure if it has been mentioned, but the increase in ticket prices is probably directly related to the collapse of record and CD sales over that past 20 year. Back in the day when live concerts were "cheap" it was partially because live concerts were used as a way to promote the sale of vinyl and CD's where artists made most of their money.
Today with streaming and considerably less revenue coming from record sales, artists have turned to live concerts as their primary revenue source, and to make a "living", they need to maximize revenue from that source.
As a result, in exchange for a nearly unlimited supply of recorded music at low prices, we need to pay significantly higher prices for live performances. It's a tradeoff. Not sure if it was worth it, but there is not going back.
Agree, love that tool. Unfortunately it does not fully support Java 8, and that seems unlikely to change. I have never used it on a large project, I don’t think that compile times are good.
Disagree. The issues described are not with the underlying payment system, but with the integration between the merchant and their payment processor. These integrations are complex, and with thousands of merchants integrating mistakes are likely to happen.
Crypto is not going to change anything. Merchants will continue to use payment processors, and merchants will continue to make mistakes in those integrations.
From my experience in cross border payments, sanctions screening (Office of Foreign Asset Control - OFAC) is the most likely source of the problem. Most likely, your customer's bank uses a US bank as a correspondent for all of their USD payments. The correspondent bank will scan every payment instruction that they receive against a list issued by OFAC. If there is a match, the correspondent bank will not execute the payment, and will seize the money from your customer's bank's account with the correspondent. In order to get the money un-seized, your customer will need to provide his bank with a lot of documentation proving that he is not the bad guy on the OFAC list. This can take a while. Your customer is probably aware of all of this and that is why he is not hassling you.
So yes, the banking system did eat his money, but that is what it is designed to do.
This is right, therefore, in most cases, a library should throw a checked exception, and the caller should decide whether it is an expected error and either handle it or rethrow it, or it is unexpected and rethrow a RuntimeException.
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.