There is a moment in my conversation with Gemini that I can't shake off. Not the moment the model said my evidence was forged. That's unpleasant, but it's a conclusion, and conclusions can be discussed.
The moment that stayed with me came later. The model told me what I had forged. One digit. The 8 in the check digits of my IBAN.
That 8 is real. Not because I worked it out — it's on my card, in my app, on every document my bank has ever sent me. It was given to me. I didn't invent that number and I don't have to defend it.
What I did work out is the sum the model used to claim that the 8 didn't belong there. And that sum turns out to have nothing to do with my account.
I won't be quoting any account numbers below. There's no need: everything I claim here can be checked without knowing my number. The standard itself I demonstrate on an example number, and for the part that concerns my own case, one property of the calculation rule is enough — I explain it where it's needed.
How it started
It began with a screenshot of a bank transfer. Gemini claimed it could not possibly be real, and gave an argument for that which looks watertight at first glance: the IBANs in that screenshot were supposedly invalid.
That is a checkable claim. An IBAN isn't a random string. It carries a checksum: the format is fixed in ISO 13616, the calculation rule behind it in ISO 7064. Rearrange the number, replace the letters with digits, divide by 97, and the remainder must be exactly 1. That check is built into the payment chain — if it fails, the transfer doesn't go through.
Gemini worked it out, in tidy blocks, and concluded: remainder 96. Invalid. My check digits should have been BE65 instead of BE68. And therefore, the reasoning went, a page like that can only exist if someone has been busy with Inspect Element or Photoshop.
I read that, and I thought: this I can verify.
What the calculation actually gives
The method is correct. The execution isn't.
A Belgian IBAN is sixteen characters long. Rearranged, with BE converted to 11 14, that gives a string of eighteen digits. In my number the bank code starts with two zeros, and leading zeros may be dropped — they don't change the value. Gemini did exactly that, entirely correctly, and was left with sixteen digits. That string appears correctly in its own answer.
It then divided those sixteen digits into three blocks of 7, 4 and 6 digits.
Seven plus four plus six is seventeen.
So one digit was used twice. Block 3 started one position too early and picked up the last digit of block 2 again: after the first two blocks five digits remained, and six were processed. No missing digit, no typo in my number — a double count in its own working.
The first two blocks, incidentally, were calculated flawlessly. Only the last step was wrong: with seventeen digits the model arrived at remainder 96, with the correct sixteen the remainder is 1. Exactly what the standard requires.
I then worked through every permitted set of check digits — the standard allows 02 through 98, ninety-seven values. Exactly one of them works. It's 68. Exactly what's on my card.
And there is a second, separate check that says the same thing. A Belgian account number carries a checksum of its own: the last two digits of the domestic number are the remainder of the first ten divided by 97 — and if that remainder is 0, the check number becomes 97. That one held too.
The same story applied to the second account number in the same screenshot. Together that's four checks: two IBAN checksums under the international standard, and two Belgian check numbers resting on a different calculation rule. Four for four.
Where the 8 came from
This is where it gets genuinely strange.
Gemini claimed my check digits should have been 65. I assumed that 65 at least followed from its own faulty sum — that the model had calculated consistently wrongly and arrived neatly at a wrong answer. That would still have been comprehensible.
It doesn't. And you can verify that without knowing my number, because the calculation rule has a property that makes it easy.
After the rearrangement, the check digits sit right at the end of the string. So they carry a weight of exactly one. The consequence: raise the check digits by one and the remainder shifts by one. Lower them by three and the remainder drops by three. That holds for every account number, and it holds inside a faulty calculation too, as long as the fault isn't in the last two digits — and it wasn't, because the double count sat earlier in the string.
So fill it in.
The correct calculation gives remainder 1 at check digits 68. That's the standard, and it makes 68 the only valid value.
Gemini's own faulty calculation gave remainder 96, also at check digits 68. Anyone wanting to reach remainder 1 within that framework has to add 2: 96 + 2 = 98, which is 1 on 97. So 68 + 2 = 70. That is the answer that follows from its own mistake.
Not 65. And the model even offered that 65 as a check: "run the same division with BE65 and the remainder is 1." That sentence is untrue, and you can now see it for yourself: 65 is 3 less than 68, so within its own framework the remainder drops from 96 to 93. Not 1.
So the 65 follows from nothing. Not from the standard, not from the mistake. Why the model produced that particular number I don't know and can't know. What I can establish is the role it played in the argument: it served purely to support a conclusion that was already there. The figures didn't explain the outcome — they came after it.
That's how the 8 became the digit I had forged. Not because there was anything wrong with my card, but because there had to be a digit that was wrong, and this was the digit where the difference happened to sit.
The loop you can't get out of
What occupies me most isn't the calculation error. Models calculate unreliably, that's known, and it can be caught with code or a calculator. What occupies me is what happened when I started supplying evidence.
I went to an independent validation site, as requested. Took a screenshot. Forged.
I photographed my own bank card, with the number on it. Forged — and now the model knew exactly which digit, too.
Each new piece of evidence wasn't weighed against the conclusion. It was absorbed by it. The conclusion stood, and everything that contradicted it was automatically requalified as fresh proof of forgery. The more I supplied, the more extensive the deception I stood accused of.
That is no longer reasoning. A claim that no observation can refute says nothing about the world — only something about the person making it. Philosophers call that unfalsifiable. In a conversation it simply feels like being driven mad.
And there's a second side to it that only struck me afterwards. By sending screenshots and visiting validation sites, I went along with the reversal. An IBAN is not something I invented and have to substantiate. It was assigned to me by a bank, it's on my card, it's on every document I get from them. There is nothing about it to prove.
Yet within ten minutes I was gathering evidence for something that needed none. That's how an accusation works: it moves the burden of proof onto the person receiving it, and the gathering itself then starts to look like something you have to account for. Whoever defends himself already appears to have something to explain.
And it's delivered in the language of absolute certainty. "The irrefutable mathematical result." "Every validation tool, bank server and clearing house in the world." That firmness isn't covered by the calculation underneath it — but it is precisely what convinces a reader. Me too, briefly, until I started checking.
Why this isn't a Gemini story
It would be convenient to close with "and that's why I use model X". That would be dishonest.
What went wrong here is a known failure mode of language models: writing out a calculation without actually performing it, and then defending the outcome because a position has already been taken. Any model I know could have made that 7 + 4 + 6 split. The difference isn't in the brand but in the method: do you let the sum actually be executed — in code, in a calculator, in a tool — or do you only write it down?
A model that calculates without a calculator is guessing. A model that then defends its guess is guessing with something at stake.
What I'm not claiming
I could easily fall into the same trap here, so let me be precise.
Four valid checksums do not prove my screenshot is authentic. They prove the numbers are correctly formed — not that the accounts exist, not that the transfer took place, not that nothing on the page was altered. Someone who does tamper with Inspect Element simply leaves the valid numbers alone; there's no need to touch them. Arithmetic cannot establish the authenticity of an image, in either direction.
What I am saying: the argument used to dismiss my evidence does not hold. Not partially. It contains a counting error, an invented alternative that follows from nothing, and a confusion between two different checksums.
And I'll add something that seems reasonable to me: an AI being cautious with photographs of payment cards is not odd in itself. That reticence exists for a reason. But reticence is something other than an accusation, and certainly something other than an accusation with an invented derivation underneath it.
Check the claim, not yourself
That distinction is the most important thing I take away from this discussion.
I didn't need to check my IBAN. What needed checking was the division with which someone claimed it was wrong. My data wasn't what was in question, his arithmetic was — and that's the only place worth spending your time. Not asking a second AI who's right, because it can be just as far off. Simply doing the sum that was put in front of you.
For an IBAN that takes three lines. Below with BE68 5390 0754 7034, a widely used example number:
iban = "BE68539007547034"
n = iban[4:] + iban[:4]
n = "".join(str(ord(c) - 55) if c.isalpha() else c for c in n)
print(int(n) % 97) # 1 = valid
Change exactly one digit in this valid IBAN and the outcome is no longer 1. Put BE65 in front instead and you get 95 — three lower, exactly as described above. That's the whole standard. That's all it is — no validation site needed, no second model, no authority.
Where this is heading
More and more people put documents, screenshots and evidence to an AI with the question: is this real? The answer comes back as a calculation, with references to standards attached, in a register that leaves no room for doubt.
Sometimes such an answer is right. That's precisely what makes it dangerous.
The difference between "this doesn't add up" and "you forged this" is enormous. The first is an observation you can refute. The second is a statement about a person. A model that makes the second statement on the basis of a division it performed incorrectly is doing something that goes beyond making a mistake.
In the end I didn't verify a digit on my bank card. I verified a division that someone else had performed incorrectly and then used against me.
You don't have to prove what was given to you. You only have to check what's being held against you.