IT-fout veroorzaakt dubbele afschrijvingen bij BNP Paribas Fortis in België

Door een IT-fout is er woensdagmiddag bij sommige Belgische klanten van BNP Paribas Fortis twee keer geld afgeschreven van de rekening. Het gaat om ongeveer zeven procent van de transacties volgens de bank.

BNP Paribas Fortis is de fout aan het rechtzetten en verwacht uiterlijk donderdag de fout bij alle getroffen klanten te hebben hersteld, meldt HLN. Klanten hoeven hiervoor niets te doen volgens de bank, de fout wordt vanzelf rechtgezet.

Het gaat niet alleen om overschrijvingen, maar ook om betalingen in winkels of geldopnames bij de pinautomaat. Om hoeveel transacties of klanten het precies gaat, maakt de bank niet bekend. Een woordvoerder van BNP Paribas Fortis laat tegenover HLN weten dat ongeveer zeven procent van het totale volume dubbel is geboekt.

Betalen, pinnen, contactloos

Door Robert Zomers

Redacteur

08-09-2022 • 11:42

120

Submitter: Admiral Freebee

Reacties (120)

120
114
41
1
0
48
Wijzig sortering
een backup teruggezet en enkele transacties opnieuw laten uitvoeren ofzo ? Ik heb het als email admin wel eens voorgehad met een mail queue in Qmail, blijkbaar kloegen klanten nadien over dubbele aankopen. ( kpn winkels in NL hun gsm bestellingen bleken via email uitgewisseld te worden :+ ) Die had ik niet zien aankomen op mijn Belgische mail relay 8)7
Je zet op het mainframe niet even een backup terug. En je voert op het mainframe niet zomaar even wat transactie's in. Integendeel, (bijv). swift-betalingen (in-en uitgaand) is een apart subsysteem en na validatie laadt je de transactie's naar het mainframe. Idem voor geldautomaten effecten-administratie, hypotheekadministratie etc. Een aantal van die imports draaien ieder kwartier, of nog korter na elkaar en een aantal draaien slechts één keer per etmaal (of zelfs per maand, denk aan renteberekening, hypotheken).

Het meest waarschijnlijke is dat men een foutieve transactie heeft gevonden in een log-bestand over zo'n importbestand op het mainframe en ipv alleen de foute transactie te corrigeren heeft men per ongeluk het importbestand opnieuw aangeboden.

Een voordeeltje is wel dat er door zo'n actie geen geld buiten de deur komt. Daarvoor moet je (bijvoorbeeld bij swift) een upload naar het swift subsysteem doen. Of naar de interface met de BankGiroCentrale (etc.) En voorzover ik begrepen heb, hoef je daarom niet toestemming te hebben van de ontvanger voor terugboeking, het is alleen maar wat boekhoudkundig "getover" op interne rekeningen.
Zou het nog echt een mainframe zijn? Mag toch echt hopen dat we daar van af zijn. Neemt niet weg dat het inderdaad in principe niet simpelweg een backup terugzetten zal zijn geweest.
Ik ben inmiddels gepensioneerd dus 100% zeker kan ik dat niet stellen. Maar na ruim 40 jaar gewerkt te hebben in een door Nederland / België / Luxemburg genationaliseerde bank (ik noem even geen namen) kan ik dat wel met iets meer dan een 'waarschijnlijk' (staat er een mainframe) afdoen.
En ik weet het zeker. 🙂
Dit soort dingen is waar LinkedIn voor gemaakt is, zoek op AS400 of ander mainframe product + naam van bedrijf en bingo er staat een functie open voor iemand wie deze kennis heeft.
Verschilt, de banken waar ik voor heb gewerkt (met name spaarbanken en hypotheek verstrekkers) hadden geen mainframe draaien. Dat wil echter niet zeggen dat er geen draken van bank pakketten worden gebruikt ;)
Het is nog mainframe, trust me.
Bijzonder dat elke transactie niet meteen een uniek ID krijgt in de transactie database, blijkbaar.
Als je een insert in plaats van een insert-update doet krijgen beide transactie's een ander ID.

Ik zie ook niet in waarom ik niet, bijvoorbeeld 2x 200 euro uit een betaalautomaat kan halen. Doe ik wel meer. Hier heeft een automaat een transactielimiet van (iets minder dan) 200 euro. Als ik 500 euro nodig heb sta ik binnen een paar minuten 3 x bij dezelfde automaat te pinnen.

En ja, dat is me ook wel eens in een kledingzaak overkomen. Heeft mijn vrouw eindelijk haar jurkje gevonden en staat we bij de kassa af te rekenen komt mijn dochter met hetzelfde jurkje. Doe die ook maar. Sorry meneer, ik heb al op totaal gedrukt. Worden twee transactie's. Exact hetzelfde bedrag.
Dat zouden dan ook 3 verschillende ID's moeten zijn, want dat zijn 3 verschillende transacties op 3 verschillende momenten. Tijd is best wel een belangrijke factor. En tenzij iets 2x afgeschreven wordt in een batch (ik kan me bijvoorbeeld het Donald Duck abonnementje voor je dochter + 1 voor d'r nichtje/neefje zijn/haar verjaardag dat in 1 x automatisch afgeschreven wordt voorstellen) En zelfs dan is het nooit identiek, maar sequentieel.
Dat is mits: bedrijf x, y, z inderdaad dergelijke informatie toestuurt.

En niet ieder bedrijf en zelfs niet iedere bank is zo geavanceerd. Om je een idee te geven: hier wordt een spaarrekening nog geadministreerd door een inschrijving in een schriftje wat in de la ligt van de kassier. En je krijgt een tegoedbon mee waarmee je het bedrag eventueel kan opnemen.

Automatische registratie van tijd, sequence nummers? Wat is dat ? Als je geluk hebt staat het soms in het opmerkingen veld.

Nogmaals, ik heb meer dan een beetje kijk op hoe het werkt. Theorie is mooi, maar praktijk is een stuk lastiger. Of zoals ze zo mooi kunnen stellen: je maakt iets idioot-proef enkel en alleen om grotere idioten te maken.
Nou, een batch verdwijnt bij afdeling B door een storing. Afdeling A maakt een nieuwe batch aan met andere ID's anders komt hij niet door. Afdeling B vindt batch 1 terug, en speelt deze af.
Was het maar zo'n feest. Sinds Sepa kan een dubbele betaalrun gewoon tot dubbele uitgaande betalingen leiden. En betaalruns worden al heel lang niet meer ingeladen. Alles is volledig geautomatiseerd. De data gaat van systeem naar systeem, komt niemand meer aan te pas.
Stel je voor, dan sta je bij de supermarkt... saldo ontoereikend, betaal anders. Hopelijk is dat bij niemand gebeurd want je bent op dat moment echt hulpeloos: contanten pinnen lukt dan natuurlijk ook niet.
Dan loop/ rijd je naar huis. Haalt contant geld uit je kast/ spaarpot en reken je het als nog af. Toch?

Geen saldo moment vaak genoeg meegemaakt tijdens studie. Kan er niet echt wakker van liggen.

Maak het niet groter dan het is. De caissière ligt er ook niet wakker van, niet de eerste en ook niet de laatste. Levert alleen extra werk op voor de vakkenvullen als je niet terug komt.
Jij gaat er vanuit dat mensen cash in huis hebben.. veel hebben dat niet meer..
Tja, dan gaan velen toch even moeten gaan nadenken of dat nou wel zo'n goed idee is. Alles digitaliseren is leuk en handig maar feit is dat het wel eens stuk gaat. En dan moet je toch wat...
En hoe kom je aan je cash geld? Uit een digitaal apparaat.
Dus zeggen 'ja als de digitale apparaten het niet doen is cash handig' gaat alleen op als jij standaard een grote voorraad cash bewaard in je matras.
Waarom een grote voorraad en waarom in een matras? Gewoon iets van 100-200 oid op een veilige plek, paar tientjes op zak voor het geval. Dat is toch geen grote voorraad cash? Dan heb je in elk geval genoeg om gewoon je boodschappen te kunnen doen als er eens wat fout loopt. Niets geks aan en het bespaart je de stress en nutteloze verwijten naar onbekenden "die hun werk niet doen" zoals sommigen hier lijken te beweren. Het blijft techniek en dat is nu eenmaal niet feilloos.
Ik kan je garanderen dat 100-200 euro voor honderdduizenden mensen een grote voorraad is! Die paar tientjes in hun portemonnee hebben ze alleen aan het begin van de week, want dat is hun budget voor de hele week.
Ook best zo’n bedragen in huis hebben, voor het geval je partner overlijdt in België.
Dan worden ook al je rekeningen en kaarten geblokkeerd tot vadertje staat (enkele weken later) bepaald heeft of en hoeveel erfenis recht er is te betalen.
Volgens KBC is de regel als volgt:
/quote
Als langstlevende echtgenoot of wettelijk samenwonende partner kun je op een niet-geblokkeerde rekening een beperkt bedrag uit de tegoeden ontvangen.

Bij de melding van het overlijden kun je zelf aangeven welke rekening je als leefgeldrekening verkiest. Dat mag de gemeenschappelijke rekening zijn. Op die manier kun je je debetkaart en in bepaalde gevallen je kredietkaart blijven gebruiken.
/unquote

Tenzij ik een en ander niet goed begrijp, kun je gewoon je betaalkaart blijven gebruiken en geld opnemen.
Ik probeer altijd rond de ton te hebben liggen.

Ik moet harder proberen :+ tot nu toe enkel een waterton

[Reactie gewijzigd door Morress op 28 juli 2024 12:57]

Anoniem: 1533372 @ToolkiT8 september 2022 12:34
Ik gebruik praktisch altijd PIN.
Maar toch heb ik altijd wat cash in mijn portemonnee zitten, precies voor dat soort gevallen.
Ik heb daarvoor een credit card. Die gebruik ik bijna nooit maar fijn dat ik hem heb.
Met credit card kan je gewoon cash pinnen
Ze gaan wel moeten als Maestro binnenkort verleden tijd is.
In sommige AH vestigingen wordt die wel aanvaard, hangt dus af van waar je het probeert.
Elke Jumbo accepteert dan weer wel credit cards.
Dat is dan een goede les voor die mensen en dat overkomt ze dan ook geen 2e keer meer :)
Als we 'goede lessen' moeten trekken uit elk falen van een persoon die z'n werk zou moeten doen, is de originele wijze les dan niet eerder 'doe je werk en maak geen fuckups, zodat andere daar geen hinder van hebben'?
Laten we inderdaad als regel instellen "niemand maakt ook weer een fout".

Maar serieus: Het is natuurlijk wel goed om enigszins voorbereid te zijn op het uitvallen van betalingsverkeer, uitvallen van gas/water/elektra/internet, etc, in ieder geval voor een korte tijd. Daar is dit een mild voorbeeld van denk ik. Alsnog vervelend om plots niet te kunnen pinnen bij de kassa natuurlijk.
Fouten zijn om van te leren, niet?
Maar ieder weldenkend persoon zorgt dat er voor noodgevallen altijd wel iets beschikbaar is, iig een bedrag aan cash. Al is het maar 50-100euro om bijv een taxi, een keer boodschappen oid te kunnen regelen.
En waarom zou ik contant geld in huis hebben voor die één keer in 10 jaar dat mij dat MISSCHIEN overkomt?

Ja ik heb vaak wel wat contant geld. maar dat is echt minimaal. En zeker niet genoeg om grote boodschappen te betalen.
Daarom neem je ook wat geld mee als je gaat winkelen, dan heb je dat probleem nooit. Ik ben al vaak een lange rij winkelkarretjes voorbij gelopen omdat er weer eens een pin/kassa storing in de winkel was, contant geld wordt altijd nog gewoon geaccepteerd zonder te veel gehannes. Waarom je dag laten vergallen door een zelf gekozen spof?
Ik heb nooit cash bij me en kan me niet herinneren wat de laatste keer was dat ik niet kon pinnen. Volgens mij zijn die storingen helemaal niet zo frequent.
Ik heb een stuk vaker moeten wachten op omaatjes die in centen moeten en willen betalen. Daar kan geen een wachtrij tegenop hoor.
De omaatjes voor mij in de rij die een pinpas gebruiken nemen altijd rustig de tijd om het pasje uit de portemonnee in de handtas te graven (die ze daar in niet kunnen vinden) om vervolgens dat ding drie keer verkeerd in de terminal te steken waarna ze de pincode half vergeten zijn. Het probleem met trage omaatjes aan de kassa ligt niet aan het gebruikte betaalmedium ;) .
Dan haal je wat van je spaarrekening af. En als je alles tot de laatste cent opmaakt koop je de helft en gaat verder met je leven.
ditto, niet iedereen heeft geld op een spaar rekening..
Met name de sociaal economisch zwakkeren zonder financiele buffer kunnen met dit soort dingen in de problemen komen..
Tsja is maar net de vraag met wat voor soort bedragen de fout is opgetreden.
En de gevolgen kunnen veel groter zijn dat wat je nu schetst, zoals een paar jaar geleden wel bleek.
Huur werd door foutje 2x afgeschreven, waardoor een incasso van een loterij mis ging en deze persoon dus geen recht had op de miljoenenprijs die toevallig net op het lot viel wat dus eigenlijk niet betaald was.

Voor zover ik weet heeft deze persoon de aantoonbaar geleden schade niet kunnen verhalen en de prijs dus ook niet gekregen.
Foutje, bedankt!
Ik weet niet of dit hoegenaamd het geval was geweest. Het zijn twee aparte transacties. Als er voldoende saldo beschikbaar was voor één transactie maar niet voor twee, dan zou die eerste transactie toch gewoon zijn doorgegaan en was er in de supermarkt geen probleem....
Sommige incasso's zijn "dwingend" of hoe die term dan ook maar is hiervoor.
Dat weet ik nog wel uit mijn studententijd, dat de incasso voor collegegeld eraf ging ongeacht het saldo.
Dus stond je dan verder rood dan wat je rekening eigenlijk toeliet.
Stel dat je een dergelijke transactie dubbel hebt, dan sta je dus nog veel verder rood dan je zou kunnen dus kan dat wel degelijk serieuze gevolgen hebben.
Een dwingende incasso, dat bestaat in ieder geval niet meer in het SEPA-tijdperk…
Ik kan nu niet vinden of het uberhaupt de juiste term is, danwel of er nog steeds een dergelijk systeem bestaat.
Echter kwam wel dit tegen: https://www.rabobank.nl/p...sso-bij-onvoldoende-saldo
Oftewel incasso's vinden wel plaats, maar worden na 4 dagen alsnog teruggeboekt als je saldo dan nog niet toereikend is.
Kan alleen niet vinden of een pin-transactie dan wel zou kunnen werken. Vermoed van niet want dat is iets wat een bank niet "terug kan boeken".
Dus in essentie is het effect hierbij nog steeds hetzelfde als een "dwingende" incasso, alleen dan wat grootschaliger aangezien alle incasso's dus nu voor 4 dagen eigenlijk hetzelfde zijn als wat vroeger een "dwingende" incasso was.
Er is ook bij Rabobank dus geen dwingende incasso.

De bank voert de incasso uit zelfs als je rekening in de min is. Ze verleent je dus een service.

Indien je na vier dagen niet voor de nodige fondsen hebt gezorgd, wordt het incasso vooralsnog geanulleerd.

Er is dus helemaal niets “gedwongen”. Integendeel onder SEPA (SDD) heb je 180 dagen het recht om aan je bank onvoorwaardelijk terugbetaling van gelijk welke incasso te vragen, dus zonder opgaaf van reden.
Je zult het dan wel aan de schuldeiser moeten uitleggen, maar dat is niet het probleem van de bank.

[Reactie gewijzigd door Myaimistrue op 28 juli 2024 12:57]

Punt is meer dat een dubbele incasso wel degelijk plaats zal vinden, ongeacht je saldo.
Dus dat de 2e incasso (die in dit geval niet plaats had moeten vinden) gaat er wel degelijk vanaf en dan kan je dus niets meer totdat dit gecorrigeerd is danwel dat je geld gestort hebt vanaf een andere rekening.
Dat laatste kan om diverse redenen lastig zijn, zoals het niet bij je hebben van een token of reader van je spaarrekening, of gewoon simpelweg geen geld om die tekorten aan te vullen.
Tja, het is gewoon een principe van SDD dat elke incasso die van een participerende bank komt, wordt uitgevoerd, en dat de debtor bank tot de 5de dag na uitvoering de tijd heeft om de transactie vooralsnog te laten terugbetalen als de debtor onvoldoende saldo heeft.

Het SDD schema voor consumenten is heel consumentvriendelijk net omdat de consument zich zeer flexibel kan laten terugbetalen als hij denkt dat de betaling onterecht gebeurde.

[Reactie gewijzigd door Myaimistrue op 28 juli 2024 12:57]

Ik weet dus niet of dat afwijkend is van wat andere banken doen.
Het was zo'n beetje de eerste hit bij mijn zoektocht naar incasso met onvoldoende saldo.
Het is in elk geval meteen wel een goed voorbeeld waarbij je dus meteen niets meer kan in een (uitzonderlijke) situatie zoals in dit nieuwsbericht. Of in elk geval mocht dat bij Rabobank gebeuren (of elke bank met vergelijkbaar incassobeleid)
Nee niet echt eigenlijk (een tijdje geleden dat ik nog in de SDD problematiek zat): er is in het SDD schema voorzien dat de debtor bank tot D+5 terugbetaling van de transactie uitgevoerd op dag D kan vragen (aan de bank van de schuldeiser), als er niet genoeg saldo is.
Of het dwingend is of niet, bijvoorbeeld de kosten van en ING betaalpakket, worden gewoon afgeschreven als je saldo 0 euro is. sta je ineens x euro euro rood op een rekening waar je niet rood op kan staan...
Als de bank je in het rood laat gaan, houdt dat een risico in voor de bank. Als de bank denkt voldoende garanties te hebben dat je de schuld zult terugbetalen, kan je in het rood gaan mits een vergoeding (de debetinterest).

Als je schulden hebt aan de bank, loopt de bank natuurlijk geen extra risico als ze dat geld afschrijft van een rekening die (daardoor) in het rood staat. De afschrijving van je rekening toont eigenlijk gewoon de schuld die je hebt aan de bank...

Als de bank daarentegen een incasso aanvaardt van een externe partij op een rekening zonder voldoende saldo, aanvaardt de bank een bepaald risico. Afhankelijk van je kredietlimiet (het maximale risico dat de bank wil lopen) zal dat dus al of niet toegestaan worden.
Ja dat klopt, maar daarover gaat mijn antwoord niet. Het punt is dat er in de supermarkt geen probleem zou geweest zijn. Da je nadien in het rood gaat, is een andere kwestie.
Nee, want stel je hebt nog "ruimte" voor 1000 euro op je rekening en er is een "dwingende" incasso van 600 euro die er door deze fout 2x af gaat. ("ruimte" als in ongeacht of je rood mag staan, of hoe ver je al rood staat)
Dan staat je rekening ineens op 200 euro verder in 't rood dan toegestaan.
Dus elke transactie daarna die niet "dwingend" is, zal falen.
Dan moet je op dat moment dus minimaal 200 euro + wat je moet pinnen overmaken om weer te kunnen pinnen.
Nou ik kan je verzekeren, in mijn studententijd was dat een serieus probleem geweest.
OK, maar dan stond je al in het rood voordat je de supermarkt binnen ging. Dat was niet het scenario. Het scenario was dat je in het rood komt te staan net omdat je aankopen in de supermarkt dubbel afgerekend worden.
Niet noodzakelijk.
Zijn ook wel rekeningen waarop je niet rood mag staan.
Vandaar ook dat ik het omschreef als "ruimte" om aan te geven dat je nog 1000 euro zou kunnen pinnen/betalen/whatever.
Dan eet je een dag niet, goed voor de lijn.

Hulpeloos is wel een erg groot woord voor iemand in het rijke westen... De kans dat deze bank er 14 dagen over doet om het te corrigeren is eveneens nihil. Oh wacht, ze zijn al klaar met de correctie.
Als je rekening hierdoor onder een bedrag zou komen waarvoor kosten worden aangerekend, gaan ze die kosten dan ook kwijtschelden?
Ik mag aannemen dat de terugboeking dezelfde valuta datum gaat krijgen je dus per saldo 'nooit' negatief zou hebben gestaan.
Als je in de tussentijd bij de mediamarkt probeert of je die nieuwe TV van 1.800,- kunt pinnen en je hebt gisteren 2.000,- gekregen terwijl je maar 1.000,- had moeten krijgen kan dat je maandbudget nog aardig in de war schoppen.
Maar is het ook dubbel bijgeschreven? Dat zie ik nergens staan.
Dat is toch de meest logische aanname, het zou wel heel vreemd zijn als dat geld bij de bank zelf terecht komt of in het niets verdwijnt.

Daarnaast zijn de boekingen dubbel uitgevoerd, en spreekt het originele bericht ook over fouten in het voordeel van de klant.
Logisch is het wel, maar wordt niet duidelijk gecommuniceerd, daarvan mijn vraag.
Buiten dat is een dubbel afschrijving/boeking natuurlijk ook vreemd. Dus zo vreemd boven op zou het niet zijn.

Bron heeft het inderdaad wel gewoon over boekingen, maar alsnog de focus op de afschrijvingen.
Door een IT-fout is er woensdagmiddag bij sommige Belgische klanten van BNP Paribas Fortis twee keer geld afgeschreven van de rekening.
Maar dus ook bij bedrijven en particulieren dubbel bijgeschreven.
Geen enkele koekwaus loopt met een TV naar de kassa om te proberen of hij hem wel kan kopen.
Zet je dan de TV van 1800 euro weer terug als blijkt dat je het niet kan pinnen?
"Ow sorry, ik heb blijkbaar toch niet voldoende geld om de TV te kopen".
Dat klopt echter, bij automatische afschrijvingen kan het wel degelijk voorkomen dat deze zal worden afgekeurd mocht er een negatief saldo ontstaan. Dit is niet bij elke bank hetzelfde (ING niet volgens mij) maar geen idee of dit bij BNP Fortis wel het geval is.
Dat is inderdaad de standard operating procedure. Klant hoeft geen schade te lijden door fout van de bank.
Elke cent moet terug. En dat bedoel ik letterlijk; elke cent.
Dit is wel een beetje een Tweakers onwaardige opmerking hoor. Om uit te leggen waarom: als Tweaker zou je enige achtergrondkennis moeten hebben over hoe dingen aan de achterkant in elkaar steken. Niet de exacte details, maar vanuit kennis op andere gebieden (bijvoorbeeld omdat je programmeert of netwerken in elkaar zet) zou je moeten kunnen afleiden dat bij een bank de bedragen die voor hun klanten worden opgeslagen niet simpelweg worden opgehoogd of verlaagd door een simpele "bedrag -= 42".

Met dat in gedachten zou je moeten kunnen weten dat opmerkingen als "Elke cent moet terug" en "elke cent" compleet overbodig zijn, omdat het systeem niet zo werkt en er waarschijnlijk verschillende manieren zullen zijn (logs, validiteitscontroles, enz) om het verlies van "elke cent" tegen te gaan.

Zelfs de simpelste boekhoudprogramma's doen dit door zich te houden aan de double-entry techniek, waardoor je genoeg informatie hebt om bij fouten naderhand uit te rekenen of het nog wel klopt en waar het mis ging. Ik zie niet waarom banken een simpelere implementatie zouden gebruiken voor het bijhouden van wat er op jouw bankrekening staat.

TL;DR: niet zo populistisch doen, er is vast rekening (hah!) mee gehouden bij het ontwerp van het systeem ;)

[Reactie gewijzigd door Stukfruit op 28 juli 2024 12:57]

Net even gekeken en inderdaad een dubbele boeking op woensdag. Aangezien het om een klein bedrag ging was het me totaal niet opgevallen. Inmiddels als correctie ook alweer terug ontvangen.
hebben ze het retroactief gecorigeerd (als in op de datum van de foute afschrijving), of ben je gewoon je intresten en getrouwheidspremie kwijt nu?
Wordt er in Belgie dan nog rente betaald over je tegoeden bij de bank?
Er is een verplichte minimumrente, al is die zo laag dat het niks oplevert. De inflatie compenseert ze zeker niet :+
Op zichtrekeningen is er geen rente, enkel op spaarrekeningen en die bedraagt voor gereglementeerde spaarekeningen inderdaad minimaal 0,11% in belgië.
Is toch zeker 0,11% meer als hier in NL :(
Was zelfs sprake van dat je geld moest bijleggen om het op de bank te mogen zetten.....
Negatieve rente heet dat dan?
Was in België ook een tijd zo bij enkele banken, maar recent weer afgevoerd.
Hoe kan dat als er minimaal 0,11% rente betaald moet worden?
Hallo,
Niet bij alle banken.
Goed weekend!
Het kan ook gebeuren dat je er even negatief door komt te staan. Die rente wordt vaak niet automatisch gecompenseerd.
Doorgaans wordt, in zo'n gevallen, teruggestort met gelijke valutadatum.
In dat geval ben je boekhoudkundig nooit negatief gegaan en wordt daarom ook geen rente aangerekend (of wordt die automatisch teruggestort).

Valutadatum kan je nagaan op uittreksel: zolang die valutadatum datum gelijk is aan de valutadatum van de onterechte dubbele afschrijving, is er geen probleem.

[Reactie gewijzigd door apa op 28 juli 2024 12:57]

Dat is dus mijn vraag.
Ik snap dat het voor de meeste weinig tot niks uitmaakt, maar langs de andere kant zou ik het schandalig vinden als de bank een voordeel haalt uit hun fouten op kosten van de klant.
Principekwestie dus.

Mij is het ooit voorgevallen (bij de vroegere Fortis) en werd het gewoon achteraf teruggestord met alle nadelen voor mij.

[Reactie gewijzigd door witchdoc op 28 juli 2024 12:57]

Mij is het ooit voorgevallen (bij de vroegere Fortis) en werd het gewoon achteraf teruggestord met alle nadelen voor mij.
Als dat een fout van jouw bank betrof, dan had jij daar geen blijvende nadelen mogen van ondervinden. Hoogstens had je een tijdelijk probleem door een te lage stand van je rekening tussen het optreden van de fout en de correctie (ik beweer hiermee niet dat dit niet erg is; alleen dat het niet blijvend zou mogen zijn).

Wanneer de fout niet door jouw bank veroorzaakt werd (bv. door de inner van een "SEPA direct debit" betaling die ten onrechte geld van je rekening neemt), dan is jouw bank daar niet voor verantwoordelijk. De terugstorting gebeurt in zo'n geval ook niet door jouw bank.

edit:
SDD is een slecht voorbeeld (zoals @Myaimistrue hieronder terecht aangeeft); hopelijk is het idee wel duidelijk genoeg :/

[Reactie gewijzigd door apa op 28 juli 2024 12:57]

Als je denkt dat er een onterechte SDD betaling is gebeurd, kan je vragen die ongedaan te maken. Je eigen bank zal dat uitvoeren, zonder je te vragen dat te verantwoorden.
Ik heb zopas mijn terugbetaling gekregen.
- Valutadatum: 7/9
- Valutadatum van de dubbele betalingen: 6/9

Niet geheel correct dus. Nu, in mijn geval doet het er niet toe, maar voor sommige mensen kan het dus wel degelijk een verschil maken.
Als zoiets gebeurt gaat men de valuta datum een dag vroeger zetten zodat de klant er geen financieel nadeel aan heeft.
Valuta datum wordt gebruikt om de interesten te berekenen (bv onder 0 gaan),

@Alex3 en @Dronium

[Reactie gewijzigd door SMGGM op 28 juli 2024 12:57]

Uiteraard worden fouten retroactief rechtgezet, dat is een standaard handeling bij banken.
De valutadatum werd ook op gisteren gezet dus ik vermoed geen tijdverschil achteraf.
Belgische banken (heb geen weet van buitenlandse banken maar ik vermoed idem) werken met valutadatums: een afboeking is doorgaans met valuta dag-1 en een bijboeking doorgaans met dag+1.
In herstel operaties zoals hier boeken ze de dubbele boeking terug met dezelfde valutadag als het eraf ging. De klant betaalt geen debetintresten op de dubbele boeking.
Even mijn nieuwe auto afrekenen...

Oh. :+
Zwaar in het rood tegen betaling:)
Het is wel interesant hoe ze dat gaan oplossen idd.. want alleen terugboeken is niet de volledige oplossing..
Precies, niet erg handig :/
Sarcasm on; Schat, je had toch een Tesla gekocht van €40.000 of heb je de meest luxe gekocht van €80.000 en in 2x betaald _O-
Dan heeft ze ook nog eens een nep-Tesla gekocht want ze kosten ietsje meer dan dat.
Oh man.. that brings back some memories.

Dat gevoel van kippenvel in je nek als je een bericht beantwoord met Ignore als hij zegt, duplicate file detected en je even te snel moet vanwege een herstel actie en gelijk daarna denkt. wait a minute.

man man man..

maar goed.. ik neem nog een koffie.

[Reactie gewijzigd door Alcmaria op 28 juli 2024 12:57]

Ik heb het ook voorgehad met één betaling, toevallig wel een van 1199,00 euro (Zeiss Batis 135mm 2.8. https://tweakers.net/pric...iss-batis-135mm-f-28.html, de dag erop netjes gecorrigeerd :)
Het is niet algemeen bekend, dat elke (micro)processor bugs heeft die eufemistisch "anomalies" genoemd worden en waar (als het goed is) omheen geprogrammeerd wordt. Bij overzetten van software op andere hardware met een andere processor, kan het dus zomaar voorkomen, dat voorheen goedwerkende software opeens niet meer werkt zoals voorheen. Dit is zomaar een voorbeeld van wat er gebeurd kan zijn.
Het is niet algemeen bekend, dat elke (micro)processor bugs heeft die eufemistisch "anomalies" genoemd worden en waar (als het goed is) omheen geprogrammeerd wordt. Bij overzetten van software op andere hardware met een andere processor, kan het dus zomaar voorkomen, dat voorheen goedwerkende software opeens niet meer werkt zoals voorheen. Dit is zomaar een voorbeeld van wat er gebeurd kan zijn.
Dat zal uit de logs blijken. Maar de hardware heeft er niks mee te maken. Tenminste, als je moet speculeren is dat een onwaarschijnlijk scenario.

Een handmatige error lijkt me logischer.

[Reactie gewijzigd door Bulkzooi op 28 juli 2024 12:57]

Dan heb je ook nog eens kosmische straling die bitjes kunnen flippen.
Ja. En heb je enig idee hoe complex dat systeem daardoor ondertussen is geworden?

Zeker met PSD2 en internationale transacties er bij.
En hoe werken die routines dan?

Overigens zijn het juist die extra hops die ervoor kunnen zorgen dat transacties dubbel uitgevoerd worden door resends.

Tenminste. Als daar geen rekening mee gehouden is. Wat ik aanneem van wel (met Unique ID’s) maar hoeft niet.
En hoe werken die routines dan?

Overigens zijn het juist die extra hops die ervoor kunnen zorgen dat transacties dubbel uitgevoerd worden door resends.

Tenminste. Als daar geen rekening mee gehouden is. Wat ik aanneem van wel (met Unique ID’s) maar hoeft niet.
Dat zeg ik; die routines boeken niet dubbel.

Op het moment dat hops en de transacties door elkaar gehaald worden, dan denk ik dat je het verschil tussen de infrastructuur van het BIS en transactionele data niet helder op het netvlies hebt.

En zoals ik al zei kan de GPDR daar invloed op hebben. Dus de transactie verloopt dan met allerlei omwegen omdat de GPDR dat voorschrijft omdat er in allerlei landen allerlei data opgeslagen moet worden.

Of wellicht is de data anoniem en heeft de GPDR geen invloed.
Op het moment dat hops en de transacties door elkaar gehaald worden, dan denk ik dat je het verschil tussen de infrastructuur van het BIS en transactionele data niet helder op het netvlies hebt.
Sorry die moet je even uitleggen? Ik begrijp niet helemaal wag je hier nu zegt.
Sorry die moet je even uitleggen? Ik begrijp niet helemaal wag je hier nu zegt.
Dan wordt het moeilijk; veel duidelijker ga je het niet gegoogled krijgen.

Wat snap je niet? De woorden? De zinsconstructie? Heb je grammaticale problemen?

BIS is in ieder geval het Bureau of Internation Settlement, (op zijn Nederlands: Buro Internationale Vereffening)

Weet je wat vereffenen is? Hops vereffen je in ieder geval niet; verkeer daarop wordt enkel gerouteerd.

Ook heb je hop waar je bier van kan maken, maar die bedoel ik niet.

[Reactie gewijzigd door Bulkzooi op 28 juli 2024 12:57]

Het deel waar “hops en transacties door elkaar gehaald worden” en het stuk waar “IK” het verschil tussen infra van het BIS en transactionele data niet helder op het netvlies heb.
Het deel waar “hops en transacties door elkaar gehaald worden” en het stuk waar “IK” het verschil tussen infra van het BIS en transactionele data niet helder op het netvlies heb.
Ik reageer zo omdat je open ended vragen dropped in een comment systeem. Ik denk dat vrij nutteloos is.

Maar data stroomt over infrastructuur, en hops kunnen data centers voorstellen. Ik kan nog veel verder gaan, maar dan kan je beter de Amerikaanse wetteksten zelf lezen. Vooral die van Delaware.
Veel definities liggen ook verankerd in standaarden, protocollen en sommige vinden hun oorsprong zelfs in product manuals.

(Microsoft heeft hiervoor geografische georiënteerde visie met een Europese data center & rekencluster strategie)

Ik zeg hop, maar in relatie tot IoT en BitTorrent kan je wellicht beter node gebruiken. Da's dan een cliënt en een supernode is dan een server.

Vandaar dat je wel juridisch moet nadenken want IoT-regels zijn een internationale effort. En vandaar dat ik je gelijk al wat definities gaf en het internationale aanstipte.

Anyway, complexiteit is geen vereiste. Correctheid is dat wel. En dat geldt overigens ook voor de verscheidene psd projecten. Ik zie dat als een politiek afvoerputje, representatief voor bestuurlijke en politieke wanorde en technology exploiteert dankbaar die zwakte.

Gelukkig is technology vrij concreet en rechtlijnig.

En wat betreft transacties? Da's alles of niks, en dat wordt bepaald door de validatie.

[Reactie gewijzigd door Bulkzooi op 28 juli 2024 12:57]

Ik betwijfel met je uitleg of je ook maar iets afweet van hoe de verwerking van betalingen gebeurt. Het gaat niet om “een paar routines”, maar om systemen die om allerlei redenen zeer complex zijn.

Er worden overigens voorzieningen getroffen om dubbele uitvoering van betalingen, dubbele boekingen te vermijden. Het meest waarschijnlijke scenario is dat er iets is misgegaan bij een uitzonderlijke operatie (systeemwijziging, incident recovery…).
Ik betwijfel met je uitleg of je ook maar iets afweet van hoe de verwerking van betalingen gebeurt. Het gaat niet om “een paar routines”, maar om systemen die om allerlei redenen zeer complex zijn.

Er worden overigens voorzieningen getroffen om dubbele uitvoering van betalingen, dubbele boekingen te vermijden. Het meest waarschijnlijke scenario is dat er iets is misgegaan bij een uitzonderlijke operatie (systeemwijziging, incident recovery…).
Complexiteit is geen vereist voor boekingsroutines.

En idd, zoiets gaat waarschijnlijk fout met manuele interventie, hoewel de boeking ten alle tijden niet dubbel uitgevoerd mag/kan worden.

Vergelijk het met een memo-boeking vs een boeking uit een sub-administratie. (Als je weet hoe boekhoudprinciepes in ERP systemen werken is dit overigens een soort wet van Meden en Perzen)

Zo implementeer ik het. En er gaat niks Live als ik niet 100% zeker weet dat er geen dubbele boekingen doorheen kunnen glippen, en ook geen boekingen over blijven. (Ook een wet van Meden en Perzen)

[Reactie gewijzigd door Bulkzooi op 28 juli 2024 12:57]

Je doet alsof je eigenhandig betalingssystemen in productie brengt.

Nogmaals: je hebt duidelijk niet het minste idee.

Ter info: ik doe al 15 jaar projecten met betalingssystemen - en toevallig bij BNPP…
Veel inhoud heb jij alvast niet bijgebracht, behalve tonen dat je niets weet over de materie.
Ik kan zo een hele hoop redenen bedenken waarin het wel mis kan gaan. Uiteindelijk is geen enkel systeem onfeilbaar. En als jij denkt een onfeilbaar systeem te kunnen bouwen dan droom je gewoon.

Jij verzint een manier om dubbele boekingen te voorkomen, met andere woorden, je past de principes van idempotentie toe. Je geeft elke boeking bij het aanmaken een unieke identificatie mee en die mag aan de andere kant maar 1 keer uitgevoerd worden. Maar wat als het toch ergens misloopt? Door een bug worden boekingen bij het aanmaken meer dan 1 keer aangemaakt met telkens een andere unieke identifier? Wat als aan de ontvangende kant van de transactie iets misloopt en daarbij de reeds verwerkte transacties hun identifier verliezen?

En zeg niet dat zoiets niet kan want hoewel de kans klein is, toont de bank hier aan dat het wel eens kan voorvallen. En als jij hele systemen op je eentje hebt ogpezet, dan heb je nog nooit gewerkt met de complexiteit en de schaal waarmee banken moeten werken.

Op dit item kan niet meer gereageerd worden.