Twelve times. The bank only noticed after the money was already gone
Friday, February 3, 2023. Someone tries to move 300,000 NIS out of the account of “Eli Friedman Ltd.” Attempt one is blocked: a security question, wrong answer. Attempt two, same amount, same destination — blocked too. The third one goes through. Nine more attempts follow that day, at amounts up to 400,000 NIS, several with wrong answers to questions like “what street did you live on as a child” and “what is your oldest son’s name.” (Somewhere in that sequence, whoever was on the other end correctly answered “which hospital were you born in” — either scandalous luck, or a lot more personal data than a bank should assume a stranger could have.) Twelve attempts, one Friday, one account. The bank only flagged that something was wrong the following Sunday.
The Bat Yam Magistrate’s Court (CC 37158-08-23, Judge Udi Haker) ruled that Bank Leumi was negligent. It was ordered to return 225,000 NIS — 75% of the transferred amount, plus interest from the date the claim was filed. The remaining 25% fell on the plaintiff, whose staff had handed the secret login credentials to office managers against internal policy. The bank argued it followed procedure and that the responsibility rested entirely with the company’s owner. The judge did not accept it: “I found that the fact that a not-insignificant number of failed attempts occurred… is unusual,” and he ruled against the bank despite some of those attempts correctly answering the security questions.
Why this is not really a question of “who clicked the button”
That is the question every case like this tries to dodge, and for good reason — there is no comfortable answer. The bank did not claim it was unaware the transfer had happened. It claimed it had no duty to know, in real time, that something was wrong. The court rejected that on the strength of a pattern, not a single event: a Friday (a quiet window, fewer eyes on it), an IP address that did not match the account’s usual one, amounts well above what was normal for the account (up to 400,000 NIS), and a chain of 12 attempts on the same day — both before and after the successful transfer. Any one of those signals alone is noise. Together, they are a pattern that should have triggered an alarm.
The problem: “should have triggered an alarm” is a technical claim that needs technical proof. It is not enough to assert that an unusual pattern existed — someone has to show exactly what the system knew, when it knew it, and what it did (or failed to do) with that knowledge.
Where an expert witness comes in, not an argument about intent
This is precisely the work that cannot be done by assertion. Someone has to reconstruct the log sequence as it actually happened, not as anyone remembers it:
- Lay out the exact timeline. All 12 attempts, by timestamp, IP address, amount and outcome — not “roughly the same day,” but second by second.
- Isolate the decision point. At what exact moment did the bank’s own alert system have enough information to flag an anomaly, measured against the thresholds the bank itself had defined?
- Separate recognition from identification. A correct answer to a security question proves someone knew the answer. It does not prove they are the account holder. That distinction sits at the heart of the dispute, and it needs to be shown in numbers, not impression.
- Test the stated alert policy against what actually happened. What the bank says it does when an unusual pattern is detected, versus what actually happened — or did not happen — that Friday.
- Translate delay into lost time. How long elapsed between the first attempt and the moment a real person at the bank could have stopped what was happening, and how much of the money was still recoverable inside that window.
Without that reconstruction, “the bank should have known” stays a moral claim. With it, it becomes a finding that can withstand cross-examination.
What this means for companies and litigators building a similar case
If you are on the receiving end of a transfer that was not stopped, do not settle for a transaction printout. Request the full login log, the transfer-attempt log (including the failed ones), and the internal documentation of the bank’s alert policy for that period. That is the material that turns “negligence” from a word into a chart.
If you represent a financial institution, the same logic cuts the other way: internal records showing the alert policy was actually applied, in real time, as stated, are the strongest defense — and they need to be built before a claim is filed, not after.
Either way, a software expert witness is what turns raw logs into a story a court can examine line by line.
Why this keeps recurring in bank-fraud cases
Because the pattern is not unique to one bank or one customer. Every bank in Israel now runs automated monitoring meant to catch exactly what happened here: repeated attempts, a pattern deviation, an unusual IP. The question courts are starting to ask is no longer “did a system exist,” but “what did the system know, when, and what was done about it.” Answering that in a way that holds up in court takes a cyber expert who can read bank logs, not just argue about them.
The above is general information and not legal advice. The specific case facts are drawn from the sources listed.