Why Monzo's bank transfers weren't working on the 30th of May (opens in new tab)

That reminds me of a race condition I encountered a while ago:

There was this massive Java application processing hundreds of parallel requests per second. For each request it wrote a line with billing information into a log file. Those lines were fine from a quick glance, but when we tried processing them later we encountered invalid dates. Those log records contained future dates as well as invalid dates like 2019-02-30. Long story short: In the end we figured out that this was caused by the date formatting not being done thread safe (might have been SimpleDateFormat, but I don't remember the details anymore), causing the date components of multiple threads to get interleaved. Ouch, I guess somebody learned a lesson back then.

Which platform gives you unformatted data if a format can't be determined? Or was the code similar to getDate(format) and format happened to be null? Was the race condition in your code or in the platform? (EDIT: I suppose these would be questions more for the developers of the third-party gateway.)

I would note that this status page says "Our FPS Direct gateway provider".

I can speak to how it works for card processing and ACH is most likely similar. To participate in payment processing in the banking network, you have to have a Merchant ID that is tied to a bank account. The processor or gateway is holding a suspense/escrow account on your behalf throughout the day and when a batch of transactions settles, it will resolve the balance difference with your bank account. The amount of payments allowed into or out of your escrow account is set by the processors based on your company's financial health and a risk analysis since if you just debited say $10 million from the escrow account and you only had $5 in your account, the processor would need to collect that debt from you, and they do not have a guarantee that they'll be able to do so. This is how it works for debit cards and bank accounts since $ amounts are real. It's slightly different for credit cards because the $ amount is in a way fictional, so they don't do the escrow holding and just temporarily "allocate" part of the credit limit (this is called an authorization) and when it is settled this is "captured", which enqueues the authorization for future processing. A few days later it will process and be included in a lump sum of funding into your merchant account. This reply is my personal understanding and meant for educational reasons and doesn't represent opinions or viewpoints of any company, and should not be considered advice of any kind and it may be inaccurate.

Another blog post from Monzo explains this in more details, see the Net Settlement section: https://monzo.com/blog/2016/01/20/how-do-bank-payments-work/

Search for bank clearing house

Bank account balances aren't money, they're IOU's, a record of debt - a bank handing out a statement that shows an account balance of $100 quite literally means the bank saying "we acknowledge that [as of date X] we owe you $100" and nothing else.

The standard money transfer from Bob to Joe is a deal where the bank says "ok, Bob, we owed you $100 but if you want that then we'll now owe that $100 to Joe instead".

It's also worth noting that's just a record of debt not reality - there has to be some legal basis for that transaction to actually change the liability between the bank and the account holder, simply changing the balance in a database doesn't change the amount of debt but just the record i.e. "bank's opinion" of that debt; and if that record/opinion is wrong, then that balance can and will be disputed, and if the dispute can't be resolved otherwise, then it'll be up to courts to decide if that debt is valid or not.

If you record just the credit without the debit, then it's the equivalent of the bank unilaterally agreeing to new debt, the bank asserting that it now owes $100 to Joe just because. It's free to do that, but it would mean that it's "books won't balance" i.e. their accounting isn't consistent with itself and doesn't match reality, so to properly account for that transaction they'd have to book a debit to their profit&loss statement since they lost money by acknowleding that balance increase i.e debt without an offseting balance/debt decrease to someone else.

The sending bank will have their Bank of England settlement account debited by the central FPS system, based on the central FPS system's view of the world, at the end of the settlement cycle.

The recipient bank will receive the money into their settlement account at that time. If the sending bank doesn't debit their customer then both sending and receiving customers will have the money in their accounts, but the sending bank will be out of pocket.

The enforcing entity here is the central bank they both have accounts with. If a customer of Monzo sends £10 to a customer of RBS, then that money never leaves the central bank, and both records are just updated. But the total amount in the central bank must still add up to the accounts of both Monzo and RBS, otherwise there is a discrepancy.

The settlement process through a central bank is a way of ensuring that banks dont need to literally send truckloads of cash to each other at the end of the day.

Monzo says to the central bank, "today I sent RBS £1,500,000", and RBS says to the central bank, "today I sent Monzo £1,200,000". So the central bank just debits Monzo's account with them by £300,000, and credits RBS's account with them by £300,000. The total amount in the central bank remains the same.

So, sure, a bank could claim they sent less money to another bank than they did, but eventually the numbers wouldn't add up, and it would trigger a bucketload of auditing, likely resulting in revocation of banking licenses, and legal issues for both the bank and people involved.

You've had a few answers about the use of central bank accounts; i'll note that this process is called net settlement:

https://en.wikipedia.org/wiki/Net_settlement

There is also a technique involving things called nostro/vostro accounts, where banks have money on deposit with each other, and the sending bank's deposit with the receiving bank is used to cover transfers:

https://en.wikipedia.org/wiki/Nostro_and_vostro_accounts

Of course, then they need to keep their accounts topped up, and they can do that by transfers through other banks, which might be central banks or commercial ones. The nostro/vostro system is suitable for use where banks don't trust each other so much, eg because they are in different countries. I think it was used more in the past, before reliable central settlement schemes were established, but i'm not sure.

You can think of net settlement as being a bit like nostro/vostro where the accounts have infinite free overdraft facilities, and so the banks never build up a credit balance, and just settle their debts at the end of the day.

Some months ago I transferred some money between two accounts at different banks. The money arrived _twice_ in two different accounts of mine at the destination bank. I contacted them and asked them to cancel the second transfer, but they just told me it would get automatically denied for insufficient funds at the origin. They also warned me that if it happened again my account might have restrictions placed on it.

An apology would have been nice, but I suppose unwarranted threats are more in character.

Personally, I prefer something written in a relaxed style rather than a formal-voice only in most cases, especially for blog posts.

Formal only generally comes across, to me, as cold and distant. Great for a persuasive essay or other mediums where you want to remove the topic from the author, not so great for communicating with your audience and wanting to come across as sincere.

If anything, a strict formal-voice only blog post would come across, to me, as contrived.

To each their own.

This is fixed for me in the latest Monzo update (came out yesterday)

If you still have problems after the latest App Store update, their TestFlight build fixed that issue.