Door Anoniem: Ik vraag me af wat Rabo hier nou precies deed, hoe ze dat deden en waarom ze het zo deden. Het idee dat je zomaar een saldo aanpast lijkt me boekhoudkundig niet kunnen, en ik vraag me af hoe dat door een audit heen zou komen.
Ik denk dat het gewoon een overboeking is naar een interne rabo-rekening.
Wat ik me wel kan voorstellen is dat ze gelijktijdig een bij- en een afboeking van 4 ton lanceerden, waarbij de afboeking direct werd uitgevoerd en de bijboeking in de wacht werd gezet. Wie weet zitten hun systemen wel zo in elkaar dat dat met één boeking van en naar de rekening van de klant voor elkaar te krijgen is. Hoe dan ook is het zaak dat de af- en bijboeking dezelfde valutadatum hebben. De valutadatum is de datum waarop een boeking administratief plaatsvindt, en dat kan een andere datum zijn dan de datum waarop de bijbehorende verwerking gebeurt (dat is de verwerkingsdatum). Het effect is dan dat als de bijboeking alsnog doorgaat effecten van de afboeking, zoals op renteberekeningen en eventuele boetes voor rood staan, worden opgeheven. Daar zijn de bancaire systemen als het goed is al heel lang toe in staat (ik heb ongeveer 40 jaar geleden bij een andere bank software voor renteberekening geschreven die, als er boekingen binnenkwamen met een valutadatum in het verleden, de hele renteberekening voor die rekening overdeed vanaf dat moment, compleet met genereren van een correctieboeking als de valutadatum voor een eerdere renteberekening viel).
Yep - het creeren van een "effectloze" af en bij boeking (afgezien van een tijdelijke blokkade tijdens de roodstand) moet bekend terrein voor de bank-systemen.
Het "bij" effect dat de rekening onbruikbaar was na de afboeking is hier gebruikt als doel - "helemaal blokkeren, NU" .
Ze zullen de uitvoer-datum van de bijboeking qua uitvoering wel aanpassen op moment dat de support-desk na contact met de klant duidelijk heeft dat het probleem (de werkelijke dan wel vermeende fraude met de rekening) opgelost is.
En waarom deden ze het zo? Een rekening blokkeren en deblokkeren kunnen ze ook. Wat wilden ze hiermee bereiken? Levert het deblokkeren van een enkele transactie minder procedurele rompslomp op? Of heeft het minder doorlooptijd en willen ze klanten niet met wachttijd belasten?
Mijn speculatie is (8 jan 22:10 ) is dat , op moment van implementatie van dat fraude-detectie systeem , "ze" (in elk geval de fraude-detectie software) NIET makkelijk de rekening kon blokkeren .
Misschien dat daar (nog) geen software ingang/API voor was. Of dat fraude detectie systeem in een domein/systeem/team draaide wat men niet de controle wilde geven om rekeningen te kunnen blokkeren.
De klant-zichtbare impact (zomaar mega roodstand) is hoe je het ook wendt of keert erg lelijk. De enige logische verklaring is dat men de 'nette' oplossing , een blokkade en goede melding "rekening is geblokkeerd, bel de bank" niet of niet snel genoeg implementeerbaar was.
De vraag komt bij me op of deze constructie als zodanig in hun systemen geïmplementeerd was of dat het een truc is die medewerkers die boekingen kunnen opvoeren hebben bedacht die een gewoonte is geworden. Die gedachte komt bij me op omdat dit alleen vanuit een heel beperkt perspectief een goed idee lijkt te zijn, en als je een automatiseringstraject ingaat bij een bank, die onderhevig is aan complexe regelgeving en actief toezicht daarop, ontkom je niet aan een breder perspectief door alle mensen die met de aanvraag in aanraking komen, waaronder verschillende die er hun goedkeuring aan moeten geven.
In de context van monitoren van transactie patronen - de uitvoering zal beslist automatisch zijn.
En de keuze voor 'blokkeren via een roodstand' moet ,zo verwacht je , een noodgreep (cq slimme truuk) zijn gegeven interne omstandigheden die de 'nette' oplossing niet of niet snel genoeg mogelijk maakten.
En het zou echt niet voor het eerst zijn als gebruikers die last hebben van een beperking in een systeem er heel creatieve trucs bedenken om omheen te werken in plaats van een aanvraag in te dienen om de beperking op te heffen — zelfs als de organisatie zijn automatisering zelf doet, de lijnen kort zijn en het vlot geregeld had kunnen zijn.
Het zou leuk zijn om ooit aan de juiste bar te hangen en te horen wat de redenen waren dat deze hack gekozen werd.
Ik heb geen ervaring intern bij financials, maar in voldoende grote organisaties is "aanvraag indienen om de beperking op te heffen" soms ECHT geen oplossing . Vooral als het geen onwil is, maar de beperking opheffen echt een heel grote verbouwing vergt van een erg cruciaal platform, of heel erg haaks staat op (andere) gewenste keuzes en criteria.