Klanten van ASN Bank zien door storing verkeerde saldo's op hun rekeningen

Klanten van ASN Bank lijken ineens geld kwijt te zijn door een storing, maar het gaat om verkeerde weergave van saldo's. Dit gebeurt in de apps van de banken en op de websites. De 'brede systeemstoring' speelt sinds donderdagochtend vroeg.

Ook tweakers zien een saldo dat nog maar een fractie is van het eigenlijke bedrag op hun spaarrekening. Sommige klanten lijken ineens meer geld te hebben. ASN Bank bevestigt in chats met klanten dat het om een storing gaat en niet om daadwerkelijke afschrijvingen. Inmiddels toont de website van de bank een korte melding van deze storing, hoewel die niet op de homepage staat.

De onjuiste weergave van saldo's bij klanten van ASN Bank speelt sinds donderdagochtend 04.00 uur, meldt het AD.

ASN bevestigt storing in chat
ASN bevestigt storing in chat met klant.

Door Jasper Bakker

Nieuwsredacteur

04-06-2026 • 11:21

172

Submitter: Maartenre

Reacties (172)

Sorteer op:

Weergave:

Ik word hier altijd een beetje nieuwsgierig van. Waar komt het weergegeven getal vandaan. :) Is het een actieve rekenactie van een beginsaldo en alle transacties sinds het moment van het beginsaldo. Zijn het saldo's van iemand anders. Wat zou het zijn...

Dat het niet op de homepage staat lijkt me om eerlijk te zijn ook niet zo nodig. Ik zou het wel bij het login-scherm zetten, of eventueel pas bij het overzicht van het saldo zelf.

Het risico van het op de homepage zetten is dat iedereen ineens extra gaat inloggen om te zien dat diens saldo niet klopt. (aan de andere kant. Hoevaak kom je op de homepage van een bank-site als je niet wil inloggen. Dat zal niet de bulk zijn denk ik?)
Volgens de bank is dit gebeurt:
„Midden in de nacht waren er updates gedraaid van ons systeem, dat gebeurt bij een bank veel vaker. In dit geval was er iets verkeerd gegaan, waardoor bij iedere klant met een spaar- of beleggingsrekening het saldo van 29 mei werd getoond.”
&
„Klanten die na 29 mei geen overboekingen hadden gedaan zagen ook niks geks, bij hen werd ook het juiste saldo getoond. Maar goed, dit brengt natuurlijk een hoop verwarring en ongemak met zich mee, dat snappen wij.”

En nu?

„Er wordt met man en macht gewerkt aan een oplossing. We gaan vannacht pas weer een nieuwe update draaien, want we willen onze dienstverlening overdag beslist niet in de weg zitten. Morgenochtend zijn alle saldo’s van al onze drie miljoen klanten weer correct zichtbaar.”
Of ergens een caching probleem, dat je een bedrag van willekeurig account laat zien.
Caching van een saldo lijkt me niet de beste weg voorwaarts. Dat moet 'altijd live' zijn, en niet van 15 minuten geleden. Maar allicht is het caching op een lager niveau? (geen idee wat daar (redelijke) mechanismen voor zijn.)
Betalingsverkeer is behoorlijk complex en op het moment dat je een betaling doet is het geld vaak nog niet daadwerkelijk verplaatst tussen banken. De intentie om dat te doen is eigenlijk vastgelegd en het daadwerkelijk administreren duurt afhankelijk van het soort betaling en onderliggende systemen langer. Deze onderliggende systemen is waar de daadwerkelijk administratie van je bankrekening gebeurt en die eigenlijk de waarheid behoren te zijn. Dit zijn ook vaak (bank afhankelijk) de systemen die al zeer lang meegaan, zeer betrouwbaar zijn maar dus ook niet live werken zoals we dat van moderne betaling verwachten. Om hier mee te praten zijn er vaak op basis van meer moderne technologie abstractie lagen bovenop gebouwd om gecontroleerd te communiceren met deze systemen.

Daarnaast zijn er nog processen die op vaste momenten (bijvoorbeeld 1 keer per dag) een check doen tussen banken wat eigenlijk neerkomt op "Hey, ik zie dat dit het totale saldo is van betalingen richting jullie. Klopt dit?".

Het saldo wat mensen in hun app zien is dan ook niet het live saldo zoals dat in het onderliggende systeem op dat moment is omdat dit systeem nog niet zover is. Banken zullen dan in veel gevallen nog systemen hierboven hebben draaien (dus nog weer boven de eerder genoemde abstracties) die dit allemaal wel live bijhouden om het te tonen in jouw app. Deze systemen zijn uiteraard wel belangrijk maar is niet waar de kritieke administratie wordt gedaan. Deze systemen wordt wel meer aan gewerkt en is de kans groter dat er door onderhoud of een bug een fout in sluipt waardoor ze niet helemaal correct de juiste data tonen.

Hier wordt overigens vaak wel gebruik gemaakt van vormen van caching en dat zou mogelijk een oorzaak kunnen zijn. Het kan natuurlijk ook iets anders zijn.

Belangrijk om te weten is dus dat in 99.9% van de gevallen dat een app niet het juist saldo toont je er relatief zeker van kan zijn dat het daadwerkelijke saldo in het ver onderliggende systeem wel zal kloppen zodra alles verwerkt is.

Disclaimer: Ik versimpel e.a. en het is al weer enige jaren geleden dat ik daadwerkelijk met betaalverkeer heb gewerkt. E.a. verschilt ook per bank uiteraard.
Het saldo wat mensen in hun app zien is dan ook niet het live saldo zoals dat in het onderliggende systeem op dat moment is omdat dit systeem nog niet zover is.
Daarnaast zijn er nog processen die op vaste momenten (bijvoorbeeld 1 keer per dag) een check doen tussen banken wat eigenlijk neerkomt op "Hey, ik zie dat dit het totale saldo is van betalingen richting jullie. Klopt dit?".
Technisch gezien zou dat met PSD2 niet meer het geval mogen zijn.

Maarja, Dit zou überhaupt ook niet moeten mogen kunnen dus tsja. dingen.
Ik heb het voorrecht om in 2 andere landen buiten Nederland het dagelijkse betalingsverkeer als klant te mogen ervaren.

In deze 2 zeer ontwikkelde landen (VS en Singapore) verbaas ik me erover hoelang het duurt voor dat betalingen daadwerkelijk verwerkt zijn. Ik reken een flesje drinken af bij de 7-Eleven en moet 2 tot 3 dagen wachten tot het bedrag daadwerkelijk van mijn rekening af is. (natuurlijk wel met een keurige verwijzing naar het betaal moment) Wat ik wil kan zien is 'pending' transacties. De bank weet dat ze verwerkt gaan worden, maar de betaling is nog niet officieel.

En dat terwijl als ik met mijn Nederlandse bankpas of mijn credit card betaal, ik de transactie wel direct zie.

Begrijp ik nu juist uit jouw reactie dat er een verschil is tussen een officiële afronding van een betaling, en een 'in afwachting' betaling? En dat we in Nederland gewend zijn dat deze 'pending' / 'in afwachting' betaling al verwerkt zien in onze rekening. Dat dit een extra laag software/database is en dat je vermoed dat hier de fout in zit. In deze extra schil, die losstaat van de daadwerkelijke transacties?

PS, mocht ik het juist begrijpen vind ik het ook wel interessant: is dit puur klantengemak van onze Nederlandse banken? Of zit er ook een stukje eigen belang in het geld alvast van mijn Nederlandse rekening af te romen voordat de betaling daadwerklijke officieel gedaan is?
Begrijp ik nu juist uit jouw reactie dat er een verschil is tussen een officiële afronding van een betaling, en een 'in afwachting' betaling? En dat we in Nederland gewend zijn dat deze 'pending' / 'in afwachting' betaling al verwerkt zien in onze rekening. Dat dit een extra laag software/database is en dat je vermoed dat hier de fout in zit. In deze extra schil, die losstaat van de daadwerkelijke transacties?
Iets complexer dan dat. We hebben in Europa ook daadwerkelijk snellere betalingen in de vorm van o.a instant payments hiermee is het merendeel van de administratie al digitaal gedaan tussen banken. Bij andere banken buiten Europa moet er vaak nog daadwerkelijk in die 2/3 dagen iets verwerkt worden. Wellicht weet je nog van jaren geleden dat geld overmaken tussen Nederlandse banken ook een dag kon duren. Dat was dan o.a. omdat dit soort betalingen aan het einde van de dag verwerkt werden bijvoorbeeld.

Maar zelfs met instant payments is het bevragen van de kernsystemen elke keer dat iemand zijn app opent voor het saldo e.d. iets wat banken liever niet doen. Soms omdat alsnog intern de verwerking iets langer duurt maar ook omdat je dit soort systemen zo stabiel mogelijk wil houden. Daar komen die abstractie lagen om de hoek kijken die dus een versie van de waarheid zelf bijhouden.

Maar nogmaals, ik simplificeer want het is echt heel complex hoe betaalverkeer überhaupt werkt en ik ben ondertussen ook al een paar jaar niet meer actief in deze sector. Wat in de VS niet uit zou maken want banken lopen daar digitaal behoorlijk achter ten opzichte van de EU en zeker Nederland. Er is minder samenwerking onderling (er zijn ook een hoop meer banken) en veel processen zijn daar nog handmatig waar deze in Nederland al jaren is gedigitaliseerd. Maar dat houdt ook in dat mijn kennis betreffende Nederlandse banken dus ook al weer redelijk gedateerd kan zijn.
Het is geen klantengemak van de banken. Het is een wettelijke eis van Europa. Betaling moet direct zichtbaar worden. We hadden al wettelijke regels dat er geen verschil mag zijn tussen debitering en creditering van dezelfde betaling. Die "rentedagen" waarmee de bank zijn kosten terugverdiende (en nog wel een beetje meer ook) zijn verdwenen. Voor Europese banken. Niet in het internationale verkeer en niet bij (bijvoorbeeld) banken in Singapore of Amerika. Daar hebben ze (voor zover ik weet) niet een soortgelijke wetgeving.

Vandaar dat ik voor mijn Nederlandse bankrekening maandelijks een bedrag moet betalen en mijn Filippijnse bankrekening is gratis totdat ik onder mijn minimumsaldo kom (P 10.000 +/- 150 Euro). Dan komt de manager klagen dat ik het saldo aan moet vullen.

Ander land, andere wettelijke eisen. Amerika en Singapore staan nu niet bekend om hun geweldige betalingsverkeer (voor particulieren). Afgezien van Fintech zijn Amerika en Singapore toch echt 'creditcard en cash' landen. Iets simpels als Pinnen is daar niet mogelijk.
Ik werk niet bij een bank dus ik zwets ook maar wat, maar wat ik in principe zou doen in deze situatie is een systeem bouwen dat gebaseerd is op jouw afschrijvingen en bijschrijvingen, maar hiervan om de zoveel tijd snapshots nemen, want voor elke saldo-opvraag de volledige historie uitrekenen kost veel te veel computerkracht en tijd.

Wat ik hier zou doen, is om de zoveel tijd, zeg eens per jaar wanneer het jaaroverzicht moet worden gegenereerd, het volledige saldo bepalen op basis van alle transacties. Dit getal sla je op. Vervolgens bepaal je om de zoveel tijd, bijvoorbeeld dagelijks, het saldo door de transactiegeschiedenis vanaf die dag bij het opgeslagen getal te voegen. Daarmee maak je weer een nieuw snapshot. Vraagt de klant diens saldo op, pak je gewoon de laatst geschreven waarde, plus alle transacties vanaf het moment, en je weet altijd het huidige saldo, maar je houdt de berekening eenvoudig.

Wat is hier dan mis? Again, speculatie, maar de bank zou bijvoorbeeld de waarde in het snapshot verkeerd kunnen hebben genoteerd, of ze pakken een verouderd snapshot, maar met de transacties alsof die op een later moment is opgenomen. Niks daadwerkelijk aan de hand met het geld, want je hebt altijd nog de historie, maar wel even schrikken.
1) De bank heeft een systeem (op het mainframe) waarin vastgelegd wordt wat het beginsaldo is (meestal 0) en wat de mutatie's daarop zijn.

2) Zelfs als je dagelijks 100 mutaties doet dan is een SQL query over meerdere jaren om het saldo te bepalen nauwelijks vertragend. We praten dan echt over 0.00001 ms of iets dergelijks. (Voor een mainframe). Er is geen enkele reden (performance) om een saldo te bereken en op te slaan.

3) Archivering per dag. Maandelijks / per jaar begrijp ik. (Belastingdienst) maar dagelijks voor die 100 transactie's die sommige klanten hebben (de meeste komen niet boven de 10 per dag uit). Zonde van de tijd / opslag. Zeker voor mainframe is dat duur.

Normaal gesproken is een bank prima in staat om meerdere miljoenen (database)records per dag te verwerken.

Echter systemen als InternetBankieren draaien decentraal. Met databases als Oracle, MS SQL en dergelijke. Daar wil je geen queries van enkele miljoenen records (als resultaat) op loslaten. Niet als je een "fatsoenlijke" reactietijd wilt hebben. Daarom krijgen die dagelijks een afslag van productie. Niet van de transactie's maar van het "saldo" per rekeninghouder. De waarde / belang / realiteit van dat saldo is "leuk voor de klant om te weten". Verder heeft het geen enkele waarde. Ze leveren (uiteraard) wel transactie's op (zoals bijvoorbeeld een geldopname) die doorgesluisd worden naar het mainframe. En eventueel (betaling) eerst een goedkeuring van het mainframe nodig hebben.

Banken, net zoals de meeste organisatie's, zijn niet stabiel, hun IT systemen veranderen. Dat gebeurd in fases (Ontwikkeling, Systeemtest, productieAcceptatie en uiteindelijk in Productie). Banken hebben ook cycli (dag, week(end), maand, kwartaal en (half)jaar). Voordat ze een "nieuw" systeem in productie zetten gaan ze de boel testen, inclusief de cycli.

En er gaat uiteraard wel eens iets mis. Vandaar dat ze hun Acceptatie omgeving vaak met enige vertraging gelijk houden aan productie. M.a.w. het is heel normaal dat hun Acceptatie omgeving 1, 2 of zelfs 3 dagen achter loopt op de productiegegevens. Maar als er een belangrijke release is, dan wil dat nog wel eens korter zijn. In de eerste week van een maand / kwartaal kan het dus heel normaal zijn dat er een acceptatieomgeving geladen wordt die een week oud is. En dat gedurende de werkdag 3 of meer acceptatieruns gedraaid worden (om alle mogelijke scenario's te testen). En ja, daar zit dus ook gewoon handwerk bij. Laden van productiebackups in Acceptatie. Herladen, hertesten.

Neen, het is niet de echte productiedata (mainframe) maar gewoon een verkeerde decentrale backup inladen voor InternetBankieren (want ja, die WeRo implementatie komt eraan). Of wellicht was het gewoon voor testen voor een bugfix.

Heeft verder geen enkele impact (vandaar dat het vannacht gewoon opgelost wordt) afgezien van wat buikpijn bij degene die een typefout heeft gemaakt bij de restore.
Ook voor korte momenten wordt er gecached. Zeg maar 5 a 10 seconden. Hier merk je als gebruiker niets van maar de resources van een bank wel.

Alles is cache tegenwoordig waar je als gebruiker mee interact. Bijna niets is echt live en dat hoeft niet om 15minuten te gaan.
Goede vertrouwen in de betrouwbaarheid van de systemen zeg... zoals je terecht aangeeft, wat is het saldo dan wel?

Ik mag toch hopen dat banken wel eens van de term ACID gehoord heeft :).
Misschien zijn ze aan het experimenteren met eventual consistency.
Dat gebruiken ze al lang hoor
Welk van de 4 denk je dat er fout gegaan is?

Het saldo van 28 mei tonen zou het gevolg kunnen zijn van een hangende transactie. Totdat er een commit volgt zie je het oude saldo, maar je ACID wordt gegarandeerd doordat die transactie alleen met een commit, rollback of crash kan eindigen.
Banken gebruiken systemen waar een saldo echt niet zomaar veranderd; als de boekingen na een dag niet exact 0 zijn (debit/credit). Met enige ervaring kan ik zeggen dat dit een cache probleem kan zijn: Echte (COBOL) API-aanroepen zijn duur dus wordt er veel gecached; kan zijn dat de cache-keys niet helemaal goed staan en dan krijg je dit... Typisch iets dat in een test-omgeving gemist kan worden.
Heeft niets te maken met cache.

Banken administreren centraal (mainframe). En die gegevens worden verstuurd (afslag) naar decentrale systemen zoals ATM, iDeal, Internet bankieren. Dat gebeurd iedere nacht.

Regelmatig wordt (voor test) dezelfde gegevens gekopieerd naar de acceptatieomgeving. Vaak met een dag of twee vertraging. Of bijvoorbeeld voor testen op de einde-van-de-maand-verwerkingen.

Zeker als je nagaat dat 29 mei nagenoeg een einde maand betekent; klinkt dit meer als "fuck, ik heb de decentrale productie overschreven met testdata".

Ik denk dat er nu ook iemand is die ontzettende buikpijn heeft.
De productie overschrijven met testdata lijkt me echt veeeeel onwaarschijnlijker.
Integendeel.

Je test uiteraard in "Ontwikkeling" en in "systeemTest". Maar je test uiteindelijk ook in "productieAcceptatie" voordat je het life in "Productie" zet. Afgezien van naam en datum is "productieAcceptatie" gelijk aan "Productie". Maar het blijven testgegevens.

Voor je iets in productie zet echt wel even testen of al je systemen (ook decentraal) wel alles aankunnen. Werkdag / Weekend / Maand / Kwartaal / Jaar etc).

Het is dan ook niet ongebruikelijk dat jouw "productieAcceptatie" omgeving afwijkt van "Produktie" en wellicht 2 / 3 / 4 dagen (of zelfs weken) voor of achter loopt.

Het is ook gebruikelijk dat je de acceptatieomgeving "out of cyclus" ververst. (Je wilt geen maand wachten met het testen of de maandovergang wel goed gaat). En ja, dat gebeurd dus handmatig.

De meest waarschijnlijke oorzaak is dat men ipv " refresh acceptatie met data van (bijna) eind mei" toevallig de verkeerde doel opgaf en dat men het decentraal systeem van productie refreshed heeft.

De oplossing (vannacht wordt het hersteld) duidt daar ook op: dat is voor productie namelijk de standaard refresh die iedere avond gebeurd.
Hier (https://www.asnbank.nl/se...ldo,voor%20het%20ongemak.) staat inmiddels dat het saldo getoond zou kunnen worden van 29 mei.

Misschien ergens in de keten kapotstuk gegaan?
Misschien een back-end systeem verkeerd gelinkt, dat er gegevens 'kwijt' zouden lijkt niet aannemelijk. Benieuwd of transacties wel kunnen.

I.i.g. aardige snafu, zo raak je wel klanten kwijt.
Misschien niet met zo'n ding an sich, maar reken maar van wel.

Bij een bank stellen mensen toch hogere eisen aan betrouwbaarheid.
- (nevermind, geen toegevoegde waarde)

[Reactie gewijzigd door Merik op 4 juni 2026 14:29]

Grote vraag is, hoe toon je aan dat je saldo onjuist is....
Door al je digitale afschriften van de afgelopen maanden door een chatgpt te gooien en hem te vragen wat je saldo was vorige maand op een bepaalde datum en dan kan hij berekenen hoeveel je er op had kunnen hebben. Tenzij je elke maand een wisselende salaris krijgt, dan wordt het wat moeilijker.

edit: schijnbaar heeft het meer context nodig. Wat ik wil zeggen is dat je dmv een eigen lokaal gehoste "chatgpt" je afschriften kan invoeren en vragen wat je saldo zou kunnen zijn. Ik zeg ook: "door EEN chatgpt te gooien". Waarmee ik de term chatgpt als algemeen herkenbare naam voor een llm neerzet voor onwetenden. Hopelijk is het nu duidelijk dat ik niet adviseer je gegevens AAN chatgpt te geven.

Het zijn de kleine dingen die het hem doen schijnbaar haha

edit2: omg, ik zit toch op een tech site of niet?

[Reactie gewijzigd door Yzord op 4 juni 2026 15:07]

Hoe weet je of de bedragen op die afschriften nog kloppen?
Hoe bedoel je? Ik heb het over de afschriften van bijv. afgelopen zes maanden waarin gpt een patroon kan vinden in je uitgaven en inkomsten. Mag aannemen dat die bedragen gewoon kloppen toch?
Dat is dus het punt. Hoe weet je dat die bedragen kloppen? Wat als er ook een fout zit in de weergave daarvan?
Dat is de reden dat ik mijn bankafschriften nog gewoon op papier krijg.

Immutable. Kan niet retroactief veranderd worden. Bank, hacker, datacorruptie in de opslag, etc, het maakt niet uit.

Low-effort. Geautomatiseerd push systeem, ik hoef niet actief elke maand een overzicht te downloaden, want dat gebeurd natuurlijk niet. En het is het signaal om de afschrijvingen te controleren wat ik dan direct en zonder moeite kan doen.

Digitaal is niet altijd beter.

[Reactie gewijzigd door locke960 op 4 juni 2026 12:29]

Ook papieren afschriften zijn natuurlijk niet heilig (zoek met de post, hond schijt eroverheen, etc.).

Ik zou vooral zeggen: digitaal is anders, en voor beide geldt dat je de beveiliging op orde moet hebben.
Het ging over hoe je aantoont dat je saldo dat de bank laat zien niet (meer) correct is. Dat kun je alleen met historische gegevens. Of dat op papier of digitaal is maakt niet veel uit.

Wat wel uitmaakt is dat je die digitale gegevens dan wel moet downloaden voordat je saldo veranderd. Want als je saldo 'spontaan' kan veranderen, hoe betrouwbaar is de andere informatie op de site van de bank dan nog?

En dat is de crux van veiligheid. Als die afhangt van mensen die periodiek actie moeten ondernemen dan werkt het niet. Een push systeem werkt daarentegen zo goed als automatisch.
Ik vind het echt jammer (en schandalig) dat "we" geen toegang hebben tot onze eigen data hierin. Ik zou graag zelf een (offline) backup hebben, maar ben helaas nog geen nederlandse bank tegengekomen die dit toelaat (of heb die gemist). Iemand suggesties?
Je kan toch gewoon je eigen afschriften of transacties downloaden.
Onjuist. Sinds PSD2 geven alle Nederlandse banken zulke toegang.
Oh nice dit ga ik eens uitzoeken bedankt!
Mocht je me hier wat meer informatie over kunnen geven, zou ik dat erg waarderen, ik heb dit opgezocht maar helaas geen manier gevonden om zelf die informatie programmatisch te bemachtigen.
Dat gaat via Payment Service Providers. Die zijn gecontroleerd door de AFM, je wil niet dat iedereen zomaar toegang heeft.
Nee niet iedereen, maar ik heb dus eigenlijk gewoon geen toegang hiertoe (uiteraard alleen mn eigen rekeningen), terwijl externe partijen dat wel hebben. Dat blijf ik toch bijzonder vinden.


Zelf zon provider opzetten is me dan weer iets te duur.

[Reactie gewijzigd door Teun! op 15 juni 2026 21:21]

Je wil dus een bestaande provider vinden die de boekhoud opties aanbiedt die jij zoekt.
Wat voor hond heb jij dan? Die van mij schijt niet zomaar in huis.
En de ASN laat ook niet 'zomaar' een verkeerd saldo zien. Shit happens, zal ik maar zeggen ;)
Hoe weet je dat die bedragen wel juist zijn?
Dat weet je natuurlijk niet, maar dan kan het niet ineens achteraf veranderen. Dat is het punt van locke960 denk ik.
Maar als het wel veranderd en je gaat met je papieren afschrift naar de bank, denk je dan echt dat ze het voor je aanpassen?
Waarom download je niet gewoon de PDF en, als je het per se op papier wilt, print je die?
lol... Oke dus als jij je huidige saldo wilt weten pak je je stapel afschriften erbij sinds het begin en ga je rekenen?

Het is leuk voor je eigen administratie, maar in de praktijk heb je er niet zo veel aan. Als jij naar je bank gaat en geld wilt opnemen, gaan ze ook niet alles met de hand na lopen rekenen.
Maar jouw geld is wel digitaal. Op het moment dat jij met je afschriften moet aantonen hoeveel geld jij op de bank had staan, dan is er wel zo'n clusterfuck gaande, dat de bank geeneens meer de tijd of de mensen heeft om jou persoonlijk te woorden te staan. En als ze dat wel zouden doen, dan krijgt jouw bankafschrift ineens vrijwel de zelfde status als contant geld (zij het dat je enkel bij de bank terecht kan met je waardepapier). Maar dan volgt het probleem dat jouw waardepapier niet als zodanig is beveiligd en iedereen met een rekening en een beetje lef met vervalste afschriften naar de bank gaat. En ook bij de bank moet de balans wel blijven kloppen. Ze kunnen geen geld uit het niets toveren.

Kortom, in theorie leuk, in de praktijk heb je er niets aan en kun je beter groente gaan verbouwen om de apocalyps te overleven.

Overigens vermoed ik dat elke mutatie read-only wordt weggeschreven, op een manier dat enkel een kernbom de data zou kunnen vernietigen.
ja dan houdt het op haha...heb er geen actieve herinneringen aan zeg maar
Kan chatgpt überhaupt wel rekenen? Want ik kan mij herinneren dat bij een AI 2+2=5 was. (Ja ik snap dat voor patroon herkennen rekenen niet noodzakelijk is).

Daarnaast wie zegt dat jij je patroon niet hebt aangepast. Stel dat ik deze maand een vriendin zou krijgen dat is mijn patroon van nooit uit eten verbroken en ga ik misschien wel 4 of 5 keer in de maand. Of gaat mijn 15 jaar oude tv stuk en moet ik een andere kopen. Of komt de PS6 / Xbox / Steam machine uit die ik zou kunnen kopen. Of dure auto reparatie. Of je krijgt deze maand een erfenis en ben dus rijker. Of (ander 1 van de miljoen reden dat je meer uitgeeft of krijgt dan normaal). Een patroon zou ik dus als bank niet zo maar vertrouwen. Misschien iets als bijvoorbeeld de gasrekening in juli ineens 3 keer hoger zou zijn dan normaal.

[Reactie gewijzigd door Daoka op 4 juni 2026 15:10]

Elke halve gare AI kan tegenwoordig prima rekenen. Voor de complexere dingen schrijven ze desnoods een Python programmatje.
Hoe weet je of de bedragen op die afschriften nog kloppen?
Hoe weet je dat ChatGPT niet hallucineert?

De beste manier om je saldo te achterhalen als alleen het huidige saldo onbekend/onbetrouwbaar is, is door je laatste bankafschrift/jaaroverzicht te pakken. Daarop staat een saldo. Vanaf daar kan je met behulp van de transactiegeschiedenis sinds dat moment tot heden het werkelijke saldo berekenen.

[Reactie gewijzigd door The Zep Man op 4 juni 2026 12:03]

[...]


Hoe weet je dat ChatGPT niet hallucineert?
We gaan toch zelf niet meer nadenken?
Ik gooide net al mijn bankafschriften in ClaudeAI en hij gaf aan 'internal error'
"Leslie I just typed your symptoms into the thing up here and it says you could have ... network connectivity issues"
ChatGPT kan het aantal letters in een woord al niet per se correct berekenen. Het is een taal model, geen wiskundig of financieel model.

denk dat je beter onderaan je laatste transactie kunt kijken. Staan bij de meeste banken wel de mutatie plus resterend saldo op.
ChatGPT (en andere LLM's) kunnen ook andere tools gebruiken. Het zal je verbazen hoe goed ze dit soort standaard analyses kunnen doen tegenwoordig.
Dat verbaast me helemaal niks, want ben er dagelijks mee bezig, maar ook die tools moet je zelf toevoegen. Gewoon ff een stapeltje PDFs erin gooien is echt niet een goede optie.
Dat hangt een beetje af van wat je precies gebruikt. GPT 5 API met API key ? Tools zijn jouw probleem. ChatGPT in een browser? Zit een heleboel standaard in.
chatGPT app heeft een hoop, maar ook daarvoor geldt, niet per se een heel financieel pakket en ook voor veel extra zaken geldt dan weer dat er ook limieten aan zitten. Ik werk dagelijks met codex, claude, gemini, noem het maar op.

Allemaal hebben ze wel wat zeker, maar gewoon even al je afschriften er in gooien... echt heel matig idee om tot een juist totaal te komen.
Alsjeblieft, gooi je bankrekeningafachriften niet in ChatGPT... Buiten dat je dit prima gewoon zelf kan berekenen, je hoeft echt al je betalingsgegevens niet vrijwillig te overhandigen aan een Amerikaans datahonger-bedrijf.
Dat doe ik ook niet, want iedereen kan een lokale llm draaien tegenwoordig. Gemma 4 is er capable genoeg voor en dat kan iedereen wel draaien. Ik gebruikte de term chatgpt om iets te benoemen wat herkenbaar is voor velen.
...en toch adviseer je om het in chatgpt te gooien.
Door al je digitale afschriften van de afgelopen maanden door een chatgpt te gooien en hem te vragen wat je saldo was vorige maand op een bepaalde datum

[Reactie gewijzigd door EnigmA-X op 4 juni 2026 12:14]

Iedereen kan een lokale LLM draaien gaat een beetje ver. Als je het over de tweakers hebt met betere PCs Ja. Verder zijn er mensen die niet eens echt een pc hebben. Je hebt mensen die een tablet als hoofd apparaat gebruiken en ook oude/low end PCs met erg matige graphics en cpu. Daarop een LLM draaien zelfs de allerkleinste is matig at best en vaak gewoon niet de kwaliteit die nodig is voor een redelijke output.

Als je dan al de hardware hebt is een tweede of je het doet, want je krijgt wel steeds betere front end/applicaties maar welk model welke variant etc etc

[Reactie gewijzigd door PaulHelper op 4 juni 2026 12:54]

Ik hoop dat dit sarcasme is, ChatGPT of welke big tech LLM moet je nooit je bankgegevens geven. Een lokale LLM tot daar aan toe. Maar kom op nou, pak de rekenmachine erbij of gebruik gewoon je hoofd. Afschrijvingen en bijschrijvingen zijn gewoon optellen en aftrekken. Dat konden we op de basisschool al.
Ik geef het op, schijnbaar willen mensen niet lezen
Schijnbaar wil jij niet duidelijk genoeg formuleren. Ja, je zegt een ChatGPT, maar ChatGPT heeft meerdere modellen, dus je kunt met het onbepaald lidwoord net zo goed daarnaar verwijzen. Evenzo kan men denken dat je door 'een' aast op de andere grote spelers, Google, Meta, X of Mistral.

Als je nou gewoon gezegd had 'AI' of liever nog 'taalmodel', dan was je gedachtegang dat je daarmee een lokale LLM aanduidt toch beter navolgbaar. En die termen zijn voor de leken onder ons waarschijnlijk ook nog wel duidelijk.
Het gemak van dit soort adviezen verbaasd mij eerlijk gezegd wel een beetje.

Waarom zou iemand al zijn persoonlijke betaalgegevens moeten voeren aan chatgpt (en daarmee heel veel persoonlijke data moeten delen met een onbetrouwbare partij op het gebied van privacy/tracking), terwijl er gewoon sprake is van een storing?

Kom op, het is een storing. Er is uberhaupt geen enkele reden om aan te tonen of je saldo onjuist is, de storing is door ASN bevestigd.
Ik mag hopen dat dit geen serieus advies is om je bankinformatie aan ChatGTP te geven?
Wat is er mis met excel?
Of, als je je saldo ook gewoon in een kasboek achtig systeem bij houd, kun je het daarmee verifiëren. Heel AI niet nodig
Die digitale afschriften download je vanuit hetzelfde systeem als waar de fout zit.

Of doe jij dat braaf elke maand?
Welke digitale afschriften? Ik zie alleen maar toevoegingen en afschrijvingen in de lijst staan, en ik zit al zo'n 40 jaar bij diezelfde bank, maar kan volgensmij maar tot een paar jaar geleden terugkijken, dus zonder startbedrag weet je dan nog niets.

PS. Ik laat nog steeds stug elke maand op papier komen, dus ik kan het dan wel simpel met de vorige berekenen.
Ik dacht dat deze reactie satire was :'(
Als je toch bezig bent. Dan kan je het beste ook direct je BSN, adres, geboortedatum en hoe vaak je het in de week met je vrouw doet "in chatgpt gooien".
Omdat je vorige week nog 1500 Euro had staan en nu ineens 25000? Een onjuist saldo dat subtiel afwijkt ga je inderdaad niet opmerken, maar ik vermoed dat vele mensen wel bij benadering weten wat het saldo is en als ze dan een sterk afwijkende waarde zien zonder verklaring daarvoor te vinden, dan weet men dat er iets mis is.
En als je vorige week nog 1500 euro had en nu 50 euro. Hoe ga je aantonen dat je vorige week toch echt meer geld had?
Aantonen aan wie? Waarom?

ASN weet dat er een storing is.

ASN op https://www.asnbank.nl/se...do,voor%20het%20ongemak.:
Je kunt dan overboeken zoals je gewend bent. Een melding van onvoldoende saldo kun je dan negeren. Excuses voor het ongemak.
Het is een hypothetische vraag...
En als die melding wel correct is? Accept het nu (tijdelijk) alle betalingen welke aangeven dat er te weinig saldo is? Of wordt de betaling nu initieel geaccepteerd, in de queue gezet en daarna alsnog afgewezen door een ander systeem of sta je bij echt te weinig saldo ineens rood? Wat als je een rekening hebt waarop je niet rood mag staan?
En als je vorige week nog 1500 euro had en nu 50 euro. Hoe ga je aantonen dat je vorige week toch echt meer geld had?
Elke maand je afschriften downloaden en controleren en elke transactie in Excel bijhouden.
leve de automatisering!
leve de automatisering!
Vertrouwen is goed, controleren is beter.
Bewijslast van de afschriften zal toch bij de bank liggen? Dan zouden ze de afschrijvingen moeten vervalsen.
Dat vraag ik me dus ook altijd af. De enige manier om dat te doen is door alle transacties uit de hele geschiedenis van je rekening bij elkaar op te tellen. Maar dan is weer de vraag: hoe toon je aan dat de bedragen van die transacties kloppen?
Als het goed is krijg je elk jaar een jaaroverzicht van het saldo en geef je die op bij de belastingaangifte. Dat zou je startpunt moeten zijn lijkt me :)

Vanuit daar kun je dan inderdaad +en en -en tot het huidige punt. Maar volgens mij hebben sommige banken ook dat je bij de transacties het voorgaande saldo kunt zien in de details.

En je kunt ook nog je maandafschriften met saldo downloaden als PDF; ook daar is het zichtbaar.

[Reactie gewijzigd door mrdemc op 4 juni 2026 12:19]

Als het goed is krijg je elk jaar een jaaroverzicht van het saldo en geef je die op bij de belastingaangifte.
Nou. De bank geeft dit normaliter zelf gewoon door. Hoe ik niet speciaal iets voor te doen bij Nederlandse banken.
Door de facturen / bonnen erbij te zoeken of op te vragen.

Facturen zijn het bewijs.
Ik weet niet hoe het bij jou zit maar mijn transacties zijn niet puur op basis van facturen.
Bij en afscrijvingen klopte gewoon. Alleen je saldo overzicht klopte niet.
Kort antwoord: NIET.

Iets langer antwoord: dat is afgedekt door de algemene voorwaarden: je accepteert (bij het openen van jouw bankrekening) dat de bankadministratie juist is.

Hypothetisch antwoord: Je toont aan dat de database op het mainframe, wat niet aan het internet hangt, gecompromiteerd is door externe actoren/hackers. (Ik wens je veel sterkte).
In je transactieoverzicht zie je bij de laatste transactie wel het correct saldo bij "saldo na boeking"

In het rekening overzicht stonden verkeerde saldo's. Overigens is het bij mij daar inmiddels ook verholpen, wat er nu staat klopt weer.
Zit al jaren bij ASN en hebben over algemeen minder storingen dan de grote(re) banken. Misschien heeft deze storing te maken met fusie van de andere banken (regiobank en sns?) waar ze aan werken?

Ik zie iig niks vreemds op m’n rekening, alles klopt.
Zou me niets verbazen.
ASN is bezig met een grootscheepse actie waarbij o.a. oud-Regiobank klanten opgeroepen worden om via de SNS app of door naar een kantoor te komen, zich aan te melden en een scan te laten maken van hun ID-kaart en gezicht als onderdeel van het hele Know Your Customer (KYC) gebeuren wat bij wet vastgesteld is. ASN heeft er voor gekozen dit keihard via biometrie te doen. Dus: gezicht scannen, of rekening gaat na een maand op slot.

(Heb met iemand gesproken die hierop al een keer uitstel heeft gehad om het haar uit te kunnen laten groeien, want de verificatie software accepteerde hem met een ander kapsel niet - en ASN weigerde elke andere vorm van authenticatie/verificatie. Nul coulance; extra uitstel als enige tegemoetkoming. Overigens- lekker onbetrouwbaar systeem? Als je ooit eens dacht je haarstijl rigoreus anders te doen, kun je dus niet meer bij je rekening bij?)

Keerzijde hiervan is dat er een heel groot aantal klanten ineens in hun systemen bij moet komen - zo groot dat ze letterlijk in de correspondentie hierover stellen dat mensen 'in golven' uitgenodigd gaan worden.

[Reactie gewijzigd door R4gnax op 4 juni 2026 12:03]

Hier een heel relaas van iemand die een klachtenprocedure is gestart, onder de titel "Is een digitale ID-check bij de bank verplicht?"
https://www.johannakoopman.nl/id-check-bank/
Hele goede en uitgebreide referentie. Thx.
Klopt inderdaad. Ik en anderen die ik ken moesten zich opnieuw identificeren via de app (id scannen, nfc scannen en foto/kleur scan gezicht).

Was allemaal echter prima te doen. Denk dat er maar een hele kleine groep is waarbij het dan niet is gelukt. En ja, nul coulance is wel logisch als het bij wet verplicht is. Je wordt opgeroepen via brief en in de app om de verificatie te doen, dus is al ruime tijd van tevoren niet te missen. Dat velen wachten tot het laatst is niet de schuld van de bank natuurlijk ;)

[Reactie gewijzigd door drmacfaulty op 4 juni 2026 12:15]

En ja, nul coulance is wel logisch als het bij wet verplicht is.
Biometrische verificatie is niet bij wet verplicht. Het is enkel bij wet verplicht dat de bank de identitieit afdoende geverifieerd heeft. Dat kan op diverse manieren. ASN heeft erin gekozen iedereen over één kam te scheren en het allerzwaarst mogelijke middel daarvoor in te zetten.
Je wordt opgeroepen via brief en in de app om de verificatie te doen, dus is al ruime tijd van tevoren niet te missen. Dat velen wachten tot het laatst is niet de schuld van de bank natuurlijk ;)
Als je enkel bij de Regiobank een spaarrekening, deposito, etc. had - dan ben je in de loop der tijd overgezet naar SNS en daarna opgegaan in ASN zonder dat je ooit de ASN app nodig gehad hebt. Ikzelf wist hier pas van toen ik van hen een brief kreeg, omdat ik zo'n geval ben. Die brief gaf geen enkele uiterste datum of indruk dat er tijdsdruk achterzat. Alleen dat je ergens de komende tijd welkom was op een kantoor om e.e.a. te regelen. Maar de week daarop kreeg ik al wel meteen een laatste herinnering dat ik op moest schieten omdat ze anders na korte tijd alles op slot konden gaan zetten. Maar zelfs in die brief stond geen uiterste datum. Dus moet je dan opeens maar alles laten vallen en pijlsnel de eerstmogelijke dag naar een kantoor gaan. (Mijn weekend was in elk geval verpest - en telefonisch zijn die pipos op zaterdag en zondag ook op geen enkele manier te bereiken. Superslecht.)

[Reactie gewijzigd door R4gnax op 4 juni 2026 18:34]

Bij de banken waar ik rekeningen heb (3 st) weet ik alleen dat ze allemaal de ID check vereisen met biometrische verificatie. Iedereen die ik ken hebben dat ook gehad i.p.v. alleen foto. Zal denk ik zijn om hunzelf in te dekken tegen boetes voor witwaspraktijken (ING of was het ABN, anyone?).

Is wel spijtig dat het voor jou zo is gelopen, want zo herken ik het niet bij mezelf en anderen. Klopt dat in de brieven geen data staan, maar ik had echt weken de tijd voordat bericht twee binnenkwam waar jij het over hebt.

Ziet ernaar uit dat ze met die fusie toch wat meer hebben te doen dan verwacht, gok ik zo. Wellicht dat die hele batch een tijd achterliep en wel me moest in die checks voor een bepaalde deadline (hetzij wettelijk, leverancier, etc.).
Waarom alleen oud-Regiobankers en niet alle ASN klanten?
Wellicht dat dit al bij de ASN Bank verplicht was met het openen van een rekening. Ik kan mij in ieder geval herinneren dat ik zoiets moest doen bij het openen van een betaalrekening.
Dit is wel knap lullig voor een bank. Correcte saldo weergave is zo'n beetje het belangrijkste. Doe je dat niet goed, dan raak de bank vertrouwen kwijt. Wat zo'n beetje de basis is van het bestaansrecht van een bank (en onze economie).
Valt wel mee denk ik. Het belangrijkste van een bank is dat je geld beschikbaar is wanneer het nodig is. Dit gaat echt geen noemenswaardige impact hebben op ASN.
Omdat bijna niemand meer papieren afschriften heeft (afgezien van de jaaropgave), is het wel een rotklus om te controleren. De bank zal vast wel zelf in staat zijn om alles weer op orde te brengen, maar dit zou voor mij toch een afknapper zijn. Dan heb ik liever nog een storing dat je helemaal niets ziet, dan dat het fout getoond wordt.

Foute saldi betekent wel dat je mogelijk minder (of meer) kunt overboeken. Dus dat raakt m.i. toch echt de kern van het vertrouwen.

En misschien is het toch handig om af en toe je saldi/afschriften te downloaden (bijv. 1x per kwartaal).
Na (ruim) veertig jaar in het BE / NE / LUX bankenwereld doorgebracht te hebben, kan ik je verzekeren:

Een bank heeft zijn administratie op een mainframe. (En die hangt niet aan het internet, direct of indirect; daar komt geen klant of hacker zomaar bij). Vanaf die administratie wordt periodiek (dagelijks) een afslag van gemaakt voor secundaire systemen, zoals Telebankieren, ATM, iDeal etc.

Op het moment dat jij geld opneemt bij een ATM wordt er een debitering gemaakt. En een export-file die vervolgens naar het mainframe verzonden wordt. Het mainframe leest al die export-files in (ATM, Telebankieren) en stuurt vervolgens een synchronisatie. Dat gebeurd iedere x milliseconden.

Op het moment dat jij geld wilt overboeken (telebankieren) wordt er een saldo getoond dat telebank.database denkt dat jij in kas hebt. Je maakt vervolgens een transactie aan (voor 100.000) die doorgestuurd wordt naar het mainframe. Die controleert of je het wel / niet in kas hebt (danwel of het binnen je kredietlimiet past) en voert vervolgens de transactie uit en stuurt dat vervolgens naar de andere secundaire administratie's. De synchronisatieslag.

Dat jij een foutief saldo ziet in jouw telebankieren applicatie heeft geen enkele invloed op het saldo wat je wel / niet kan overboeken. Of op het werkelijke saldo wat je bij de bank uit hebt staan.

Een foutief saldo (in telebankieren etc) heeft hetzelfde effect als geen saldo: helemaal niets.
Er zit hoe dan ook een verbinding van frontend systemen naar de backend. Dat gaat vast niet per postduif, usb stick of tape. Of is de scheiding zo streng, dat hier echt geen netwerk tussen zit?

Als je verhaal klopt (en dat geloof ik) dan zit toch echt de schakelaar/controle op 'saldo tekort' of 'limiet bereikt' aan de voorkant cq wat jij de afslag noemt. En is die administratie leidend voor wat de gebruiker ziet/ervaart. Dat is de logische consequentie van gescheiden werelden tussen mainframe en alles eromheen.
Er ligt inderdaad geen netwerk. Dat is juist de secundaire administratie. ATM krijgt (via secure ftp zijn gegevens van de secundaire administratie. Administratie controleert, valideert en zet op zijn beurt de transactie klaar. Dat wordt (secure ftp pull, vaste locatie, vaste bestandsnamen, vaste lay-out, vaste adressen, validatie etc) opgehaald door het mainframe. Die transactie wordt verwerkt. (Ja er is een kleine kans dat je zo snel bent dat je meer dan je saldo op kunt nemen. Dat risico ligt bij de bank, maar dan je moet echt wel binnen een paar seconden reageren).

Telebankieren. Je boekt 100 euro over. Dat gebeurt sowieso in de webserver van de bank. Vast adres. Via een vastgesteld formaat. (Validatie). Webserver schrijft dat weg: Sessie 123, bestand xyz. Back-end server leest 123, xyz en stuurt dat door naar 123.456.789.012. Mainframe leest 123.456.789.012 uit. Valideert de hele boel. En mainframe applicatie ziet dus dat je 100 euro wilt overboeken. Stuurt vervolgens een bericht naar "authorisatie-module" (mainframe applicatie) die de boel op saldo controleert. Reageert met een Yes of No. Dat gaat naar 123.456.789.111. Telebankieren controleert of het antwoord op 123, xyz Yes of No is en bepaalt daarmee of je wel / niet die 100 euro over kan maken.

Dus, inderdaad: er ligt geen permanente verbinding tussen front-end en back-end. Er zijn wel secure, one-way, tijdelijke verbindingen. En ja, die worden inderdaad 24 / 7 bewaakt.
Er ligt inderdaad geen netwerk. Dat is juist de secundaire administratie. ATM krijgt (via secure ftp zijn gegevens van de secundaire administratie. Administratie controleert, valideert en zet op zijn beurt de transactie klaar. Dat wordt (secure ftp pull, vaste locatie, vaste bestandsnamen, vaste lay-out, vaste adressen, validatie etc) opgehaald door het mainframe.
Dus er ligt wel gewoon een netwerk? Het mainframe is geen airgapped system he?
Mijn medewerker (decentraal systeem) doet een pull ftp op jouw server. Open verbinding. Plaatst het bestand op een harde schijf op zijn server. Sessie is afgelopen. Verbinding gesloten.

Ik lees het bestand van de server van mijn medewerker (open verbinding, haal gegevens op, sluit verbinding) en sla het op mijn server op. Vervolgens verwerkt de admin dat bestand in een database.

Er lagen tijdelijke verbindingen tussen de diverse onderdelen van het proces. (En ze zijn allemaal gesloten en nimmer allemaal tegelijk actief). Ligt er nu wel of niet een netwerk?
Er lagen tijdelijke verbindingen tussen de diverse onderdelen van het proces. (En ze zijn allemaal gesloten en nimmer allemaal tegelijk actief). Ligt er nu wel of niet een netwerk?
Of ze actief zijn of niet boeit niet echt. Software defined aan/uit is echt niet hetzelfde als Airgapped.

Er wordt ook niet elke keer een stekker in of uit getrokken oid dus het netwerk (de fysieke infra) ligt er gewoon. Dat je er voor kiest om de verbinding te firewallen of helemaal niet actief te zetten boeit niet.

Anders zou een gemiddeld ETL proces ook ineens niet meer in een netwerk zitten volgens jouw definitie. Want upload naar S3 om dan daarna door iets anders verwerkt te worden (asynchroon) is in dat opzicht precies hetzelfde.

Gedeelde map op sharepoint of onedrive idem. Daar ga je ook echt niet doen alsof er geen netwerk ligt toch?
Dat gaat vast niet per postduif, usb stick of tape. Of is de scheiding zo streng, dat hier echt geen netwerk tussen zit?
Wat @kdekker hier bedoelt is de fysieke infrastructuur. ligt er een kabeltje of is het airgapped. Ik weet dan niet waar je vandaan haalt "nee er ligt geen netwerk" als dat gewoon fysiek wel het geval is. Leuk dat je dan met vast IP adressen werkt voor FTPS, maar ik denk ook niet dat je Mainframe DHCP zo leuk gaat vinden.
Er lagen tijdelijke verbindingen tussen de diverse onderdelen van het proces. (En ze zijn allemaal gesloten en nimmer allemaal tegelijk actief). Ligt er nu wel of niet een netwerk?
Er liggen permanente fysieke verbindingen tussen de diverse onderdelen van het proces. Het enige verschil met een random setje servers of computers is dat ze nooit naar meer dan 1 andere server een actieve verbinding hebben. Dus ja er ligt een netwerk?
Een storing waarbij je toevallig niets ziet kan er toch ook voor zorgen dat je niet kunt overboeken? En dat het getoonde saldo niet correct is betekent toch niet meteen dat je niet/minder/meer kunt overboeken? Dat ligt er allemaal maar net aan hoe het geïmplementeerd is. Grote kans dat in dit geval het systeem dat daadwerkelijk verrekent niet hetzelfde saldo ziet/heeft als wat jij in de app of website ziet.
Of die kans groot is, weet ik niet. Je zou verwachten dat er een noodzakelijkerwijs een relatie is tussen wat de backend weet en wat er in de frontend getoond wordt. Maar zonder kennis van de backend is het idd koffiedik kijken, al zou je verwachten dat er logica in de app zit, en je niet meer over kunt boeken dan je positieve saldo + rood staan limiet, mit niet over de daglimiet.

Het zou wat moois worden als de frontend en backend een eigen afzonderlijk leven leiden, maar goed, dat zou dan kunnen verklaren dat - hopelijk - bij ASN de backend administratie klopt en er alleen een communicatieprobleem is tussen backend en frontend. Al zal vast de frontend niet 1:1 aan de backend verknoopt zijn, maar daar zal wel wat tussen zitten (een euro-jatter ;-)).
Omdat bijna niemand meer papieren afschriften heeft
Dit soort situaties is precies waarvoor ik ze nog wel heb.
Gewoon elke maand een afschrift op officieel briefpapier van de bank.
Geen beter paper trail, dan een echt paper trail.
Jawel, ik zag dat ik vannochtend meer dan 10.000.000 euro op mijn rekening had. Ik wilde direct 100 euro opnemen maar kreeg alsnog de melding Saldo Ontoereikend. Tijd om naar een andere bank te switchen dus.
Vanmorgen 6:30 in paniek op gebeld door mijn vader.. Arme man dacht dat hij gehackt was en AL zijn spaargeld kwijt was.. Bedankt voor de storing en een bijna hartaanval van een man van bijna 70..

Tip voor ASN, meld het duidelijk op de app/browser als er een storing is die zulke inpact heeft.
In de app staat een melding dat het niet kan kloppen.
Nu misschien, niet op dat tijdstip haha
Pas als hun weten dat er iets niet klopt kunnen ze andere melden dat er iets niet klopt, dus daar zit tijd tussen het moment dat het daadwerkelijk gebeurd en geconstateerd wordt.

Blijkbaar hebben ze het dus later opgemerkt (en bevestigd) dan je vader? Ze kunnen ook niet voorbarig wat roepen want dan doen ze het ook niet goed dus ze moeten het wel eerst uitzoeken.
Het ding is dat veel bedrijven heel 'voorzichtig' zijn met melden van verstoringen.

Vaak is het intern al lang en breed bekend voordat er ooit een publiekelijk bericht de deur uit gaat. Want toegeven dat je een verstoring hebt staat slecht, dus wachten de meeste toko's tot ze er niet meer onderuit kunnen.

Nogal een gat tussen 6:30 en een tijdloze melding op de website uren later.
Ik ben wel benieuwd naar een leuke screenshot :)
Helaas, ik had maar zo'n € 200 meer dan ik al had. Ik was al meteen gaan kijken in de hoop een keer tonnen op m'n spaarrekening te zien staan.
Ik zie twee soorten paniekaanvallen na deze storing, 1e je denkt dat je alles kwijt bent. 2e je denkt dat je ineens schatrijk bent. Met afstand de leukste storing die een bank kan hebben :-)
Nou.. die 2e kan sommige mensen serieus in de problemen krijgen.

Er zijn genoeg mensen met het IQ van een schoenveter die geld zien en direct de winkel in rennen.
Vraag is wel als ze het saldo zien, of ze dan ook dat bedrag kunnen overmaken, of dat er bij het overmaken zelf al komt te staan dat je saldo ontoereikend is.
Overboekingen gebeuren uiteindelijk in backend, en dit is frontend.
Het ophalen van dat saldo getalletje gebeurt uiteindelijk ook in de backend.

En daar gaat dus obviously óók iets fout. Frontend doet niks anders dan een beetje doorgeefluikje spelen.
Geen idee.. maar als iemand 2K heeft op de rekening (Voor de hele maand) en nu ineens 6K ziet en denkt !!! JA SHOPPEN.. en dan een dag later terug schiet naar 2K minus het uitje naar de mediamarkt kunnen ze in de knoei komen.


IS het slim? Nee...
Maar het gebeurd ongetwijfeld.
Als je ineens tonnen overgemaakt krijgt... kan je beter maar je rekening direct laten blokkeren.

Voordat je gedwongen als geldezel ingezet wordt.
Eerst overmaken naar andere rekening, dan gewoon opzeggen en dan... fiesta!
Mijn pa had de eerste
Krijg prima mijn actuele saldo te zien :)
Mijn saldo is nu hetgeen wat ik had voordat ik op 1 juni onze vakantie heb betaald. Het zichtbare saldo is van ergens tussen 28 mei en 1 juni. Misschien een chronologische fout ergens?
Ik mis idd een groot bedrag aan saldo.

Op dit item kan niet meer gereageerd worden.