> someone actually had £1000 taken. They actually only had £250 worth of points in their account – however, because the Nectar points balance doesn’t refresh immediately, the fraudsters hit their account 4 times in quick succession. Leaving them with a debit of £750 in their Nectar account balance.
It's astonishing that of all the software engineers involved in programming and reviewing this system, not one of them thought to lock the DB records to prevent this (or worse, someone ordered them not to for some reason). It's so simple to do and should be top consideration when dealing with financial transactions.
I'm sure all of them thought about it. But were then told the terminals used for scan & shop or the self-scan kiosks needs a bit of slop in them to make them appear more reliable, meaning to work "offline" for a short span of time. It is a trade-off between serving real customers (meaning the majority) well but with the downside of benefiting fraudsters.
All systems have trade-offs like these. It reminds me of the phase: "Anyone can build a bridge, but it takes an engineer to build a bridge that barely stands." That applies here. Any student can build a system with locking database records, but then when thousands of people's cards don't work for minute-long lockout periods, you aren't the one doing the CS calls or getting yelled at.
The system originally worked on an overnight batch processing basis.
Each store would have a local copy of the card balances - but only for cards that had been used in that store in the past 12 months.
The first day you scanned your card in a store, you could only collect points (not redeem them).
By the next morning, your card would be included in the local database and you could redeem points - with the vulnerability that each store had its own database, and therefore you could redeem the points in multiple stores.
I thought this had been improved in recent years, but maybe not.
Everything that normal people don't like about the user experience of large computer systems can be attributed to the batch nature of how these systems were designed and often still operate. A lot of systems that feel real-time are really just batched more often.
You can register a Nectar card (giving name/postal address/email address/phone number/date of birth), but I'm not sure how much verification of these things they do.
I am not sure, but I think you might need to register to redeem points.
There would be CCTV and maybe more if they used a payment card for the purchase. Whether Sainsburys would lift a finger to investigate a small loss is another matter.
What does negative Nectar points even mean? That you have to keep shopping at Sainsburys until you've accumulated enough points to "pay back" the "debt"?
Or there is a batch update in there somewhere - which given that Nectar is over 20 years old and probably based on older systems I suspect would be a distinct possibility.
It's astonishing that of all the software engineers involved in programming and reviewing this system, not one of them thought to lock the DB records to prevent this (or worse, someone ordered them not to for some reason). It's so simple to do and should be top consideration when dealing with financial transactions.