We never got to the bottom of it, but I felt like the issue with those was specifically that they did have to be signed for.
The postman would take the general post into reception and then the normal ones would just get processed. The signed-for ones would get signed for by security. They probably then kept them at some kind of security desk, “because they’d been signed for, and needed to be secure”. Monzo staff were probably supposed to go down and get them, but due to a general lack of consistent process they sometimes went missing at the building security desk. I can easily imagine somebody putting it in a locked drawer or cabinet, then their shift ends and they go home. A different person is there later and when someone from Monzo comes down to check the post, they don’t know about the cheque in the drawer.
I always had something like that in my head anyway, no idea if it’s true!
Interestingly, it seems to have been switched on with a server-side flag rather than a change to the app code.
I’m now unable to edit the first post (unless one of the mods wants to make it a wiki) so I’ll just repost the updated list below.
Banks supporting cheque imaging in-app include:
HSBC & First Direct
Lloyds, Bank of Scotland & Halifax
Virgin Money (including Yorkshire Bank, Clydesdale Bank & B)
RBS, NatWest, Ulster Bank, NatWest International & Isle of Man Bank
Banks not yet offering support:
Co-operative Bank & Smile
Bank of Ireland
Hopefully a few of the larger banks, at least, will react. It would be good if those still limited to £500 would allow higher values. NatWest/RBS have a higher limit for business customers, but leave everybody else stuck with it too low.
Cheques have always been, at least officially, simply a way to pay another person or company without needing to know their bank details or any information at all aside from their address. Their format has also made them a useful method for payment via post; since they are really just a piece of paper nobody can tell what you are sending (so they can’t be intercepted) and only the named payee can pay in an A/C Payee “crossed cheque”, so they are relatively secure if used this way.
Cheque clearing times reduced when the Image Clearing System first launched, and the same shorter clearing times now apply to all cheques. This is because the physical cheques themselves are no longer sent to processed in a physical location, so clearing times can be sped up.
Academic studies on the functioning of economies and conventional wisdom indicates that faster payments, in general, promote economic growth and are beneficial to business. They also reduce costs in other hidden ways, such as wasted employee time from chasing up slow payment.
The EU have recently been releasing evidence on this topic, trying to spur adoption of SEPA Instant, and it was also much discussed back when Faster Payments first launched in the UK.
Also, even if a cheque isn’t paid in, you still have to make provision for it in company accounts - technically, it could be paid in up to 6 years later (the limitation time of a debt) although in reality banks are unlikely to accept cheques that old. Therefore accounting for cheques is often quite a lot of hassle, so I doubt they would be the first preference payment method for many businesses.
One simple way of managing this for businesses who pay by cheque routinely is to have a separate account just for that purpose; and transfer money in to it at the point the cheque is issued.
Cheques are very useful from a GDPR perspective as the only information the issuing entity needs is the recipient’s name and an address to send the cheque to; no need to handle any account details at all.
Presumably you would always keep records of who was sent what cheque number, just in case they forgot to pay it in or lost it (and it needed to be cancelled and reissued). Therefore, it’s not like cheques are totally secret - and they do expose your own account details anyway., so it’s the same “problem” in reverse. GDPR is often overblown and, while you do need to take reasonable steps to keep private/sensitive information secure, there is nothing in GDPR to suggest you should actively avoid using or collecting such information in the first place (other than the “principle of data minimisation”, which only applies if there is no lawful business purpose for collecting the data - i.e. if you collect data “for the sake of it”).
I’ve had a similar debate over this on the Monzo community before, where I suggested that removing account details from payments due to GDPR didn’t follow logic - and partly that was reversed, so account details do show now if you already have the person saved as a payee.
Agreed, in fact any payment that doesn’t clear instantly adds potential issues for banks due to reconciliation and processing becoming more complicated.
Minimising the amount of data any organisation holds is the biggest shortcut possible when it comes to GDPR compliance.
Of course it’s not secret or anonymous, but a business handing out pieces of paper with their own account details on is not a GDPR concern but collecting, storing, using and then deleting client banking details absolutely is within scope. There’s also an overhead involved in capturing these additional details - imagine a probate solicitor enacting a will - if they use cheques, they potentially have all the details they need already on the will, and all they need to do is confirm those details are still valid.
True, but it’s not exactly best practise - just because it is an easy shortcut, it’s not necessarily correct.
Well, technically it is (as any information that is sensitive or personally-identifiable is) but it would probably be chalked up as unavoidable for conducting business even if paying a cheque wasn’t technically “unavoidable”. But that just goes to show the inconsistent nature of how the data minimisation principle is often applied!
It would still be deemed “sensitive” under GDPR. All sensitive information is covered, not just personal details.
Sensitive information statutes automatically relates to information which could be used to identify another person, but also other information which, for a variety of reasons, could be considered sensitive or private.