Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie
×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste prijsvergelijker en beste community. Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers!

Internetbankieren bij Britse bank ligt al zes dagen plat door softwaremigratie

TSB, een Britse bank met 1,9 miljoen klanten, heeft al zes dagen te maken met ernstige verstoringen. De omgevingen voor internetbankieren en bankieren via een app zijn uitgeschakeld. De problemen doen zich voor sinds een softwaremigratie.

Klanten van TSB kunnen momenteel niet internetbankieren of gebruikmaken van de app, maar er zijn meer problemen. Zo kregen sommige klanten per ongeluk de gegevens en rekeningen van andere klanten te zien en zouden ze daar ook toegang tot hebben gehad. Zo zegt een klant tegen de BBC dat hij toegang had tot de spaarrekening van iemand anders. De bank heeft toegegeven dat dit zondagavond het geval was en betrekking had op 402 klanten. Ook zouden er problemen zijn met pinnen en het uitvoeren van betalingen.

TSB was oorspronkelijk onderdeel van Lloyds Bank, maar werd in 2015 verkocht aan het Spaanse Banco Sabadell. Aanvankelijk bleef Lloyds de it-infrastructuur beheren, maar daar is nu een einde aan gekomen. Bij het overzetten van 1,3 miljard klantenrecords naar het bankplatform Proteo4UK, dat is gemaakt door Sabadell, zijn de problemen ontstaan.

The Guardian houdt een liveblog bij over de problemen. Daarop staat dat de ceo van de bank zegt dat de problemen te maken hebben met een gebrek aan bandbreedte. De app zou moeite hebben met een groot aantal gelijktijdige gebruikers.

Eerder op dinsdag beloofde de ceo dat de diensten 's middags weer zouden werken, maar die belofte werd niet waargemaakt. Nu zegt te hopen dat de diensten vanavond weer online zijn, hij merkt echter op dat hij de it-medewerkers heeft opgedragen de diensten pas online te zetten als ze 'echt klaar zijn'. Volgens de ceo is de migratie van klantgegevens de grootste ooit in Europa.

Banco Sabadell, eigenaar van TSB, heeft maandag een persbericht online gezet waarin het de succesvolle migratie viert. Dat bericht is inmiddels weer offline gehaald, waarschijnlijk vanwege de problemen, maar nog te lezen via de cache van Google.

De problemen bij de Britse bank doen denken aan de langdurige storing die zich begin deze maand voordeed bij de Belgische bank Argenta. Daar hielden de problemen een week aan en werd ook internetbankieren en de app voor mobiele betalingen uitgeschakeld. Ook daar was een migratie naar een ander bankplatform oorzaak van de storing.

Door Julian Huijbregts

Nieuwsredacteur

24-04-2018 • 20:12

106 Linkedin Google+

Submitter: Sv3n

Reacties (106)

Wijzig sortering
Ik spreek uit persoonlijke ervaring bij meerdere financiŽle instellingen dat dat inderdaad klopt. FinanciŽle instellingen hebben te maken systemen die jaren en jaren oud zijn en nooit fatsoenlijk zijn bijgewerkt door softwareleveranciers.
Die leveranciers hebben in bepaalde gevallen (vrijwel) unieke functionaliteit en hebben daarmee hun klanten bij de ... lurven :) . Het wegmigreren van die systemen is extreem complex en HEEL erg duur.

Er zijn nog menig COBOL systemen bij dit soort instellingen, en aan de andere kant van die systemen zitten dus moderne applicaties aan de web-kant. Dan heb je vervolgens nog te maken met interne bedrijfspolitiek en culturele historie binnen dit soort organisaties (zoals bij elk groot bedrijf). Dit helpt in z'n geheel ook niet.

Daarnaast heb je nog te maken met internationele regelgevers. Regelgever 1 verplicht punt A en regelgever 2 verbiedt dat juist weer. Dan krijg je bijvoorbeeld te maken dat twee systemen fysiek (firewalls is veelal voldoende, maar ook niet altijd) nooit met elkaar moeten kunnen praten. (als in het mag 'niet mogelijk zijn'). Je complete infrastructuur raakt hierdoor dus compleet versplintert en zeer complex om te onderhouden.

Dit zorgt ervoor dat het eigenlijk een klein wonder is dat het allemaal zo goed werkt als dat het uiteindelijk doet.

Uiteraard is elke verstoring er ťťn te veel, maar het is zeker niet vreemd dat het zo nu en dan is goed mis gaat. Al moet ik wel zeggen dat een verstoring van 6 dagen wel ERG extreem is. Ik vermoed dat de betreffende toko binnenkort een verslag en uitleg aan de Bank of England en de ECB mag geven, want dit gaan dit niet tof vinden zacht gezegd.
Ik heb het al-met-al te doen met de betreffende ICT'ers die dit moeten fixen.
Nou... Je heb geen flauw idee wat er allemaal mis gaat bij banken! Ik heb er zelf ook gewerkt en inderdaad zijn migraties/updates enorme zwakke punten, je kan nog zoveel testen in een schaduw omgeving maar op (oudere) productie hardware en alle productie data gaat er veel, VEEL mis. Vaak worden de meest simpele dingen over het hoofd gezien omdat het vaak een grote logge organisatie is, met veel 'vast geroest' personeel.

Omdat er tegenwoordig alles realtime moet gebeuren en we nu allemaal internet hebben, valt het veel meer op, maar vroeger (10-15 jaar geleden) was het al opgelost voordat het nieuwswaardig was. Mensen die een ochtend niet konden pinnen omdat een batchjob was uitgelopen, 's ochtends vroeg om 6-7 uur met een rotgang je omgeving terug rollen omdat een update toch niet helemaal lekker werkt. En wie zal ooit hebben gemerkt dat onze email servers er een week uit hebben gelegen (in het NT4 tijdperk duurde een Exchange cluster restoren schandalig veel tijd). Dat je toevallig tijdens het thee halen moet horen dat ze vanavond het 'systeem' tot 22:00 open laten, dat de communicatie met een half uur de deur uit gaat naar de klanten en ze niet de juiste personen van it hadden aangesproken op de haalbaarheid van het geheel. De nachtelijke backup begon al heel vroeg op de avond (19:00) en duurde tot in de ochtend 8:00-9:00 (en soms nog later), daar moest eerst een hele grote investering voor een AS400 worden goedgekeurd met nieuwe taperobots, etc. voordat we de backup terug konden dringen zodat deze na 22:00 kon beginnen...

De software ontwikkelaars van dergelijke systemen hebben zo vreselijk veel macht en leveren vaak zo bagger werk tegen een enorm hoge prijs dat je geen kant op. Directeuren/IT Hoofden hadden/hebben bij banken hebben vaak inhoudelijk geen kaas gegeten van de materie en huren een bedrijf in om software te ontwikkelen, maar vergeten contractueel vast te leggen dat het broncode van de bank is. Zit je voor de levensduur van het pakket vast aan die specifieke leverancier en omdat je er toch niet af kan zetten ze echt niet hun beste beentje voor.
De broncode kan je niet per definitie wat mee. Het is leuk als je kan programmeren, maar dat kost natuurlijk gigantisch veel tijd en energie waar je je als financiele organisatie niet per definitie mee bezig wil houden. ("Want wij zijn bankiers, en geen softwarehuis")

Uiteraard heb je wel alle specs en unit tests en heel de bende, maar stel dat je core componenten gaat migreren, want de onderliggende hardware raakt uit support (en het OS waar het op draait ondersteund de nieuwe hardware niet, dus je moet je OS migreren, en je middlwarelaag ondersteund dat nieuwe OS niet, dus die moet ook, en je applicatie dus ook). Je hebt honderden systemen die als een spinnenweb aan elkaar verbonden zijn.

ZEER versimpelt voorbeeld:
Systeem A bevat NAW gegevens van klantensoort: Particulier en klein-zakelijk
Systeem B bevat NAW gegevens van klantensoort: Particulier uit oost-Azie (want de regionale regelgever verbiedt dat de gegevens 'hun volk' tussen die van de Europese staat)
Systeem C bevat NAW gegevens van klantensoort klein-Zakelijk uit oost-AziŽ
Systeem D bevat gegevens van alle drie de bankrekeningnummers (historisch gegroeid en toegestaan door alle regelgevers)

Stel nou dat de regelgever in oos AziŽ iets veranderd en daarmee een aanpassing aan systeem C vereist, heeft dit dus impact op B en A, en daarmee dus mogelijk ook D.

Dan heb je vervolgens nog te maken met honderden soorten financiele producten die er wereldwijd bestaan die je veelal gespreidt over systemen heen moet zetten ivm regelgeving en omdat het ooit een goed idee leek, en nu niet meer. Maar je zit er nu wel aan vast.
Je kan je voorstellen dat je voor je dagelijkse rapportages aan de Centrale Banken je dus ook weer alle systemen aan elkaar moet knopen en al die data moet correleren en verrijken om de juiste rapportages te kunnen opleveren.

En wat ik nu noem zijn alleen de 'hoofdlijnen' binnen functionele systemen. Onder water heb je ook nog te maken met regelgeving met betrekking tot authorisatie en controle op privileges (wie mag wat waar en onder welke omstandigheden). En daarbij komt zoals @Cergorach al aangaf politiek, vastgeroeste denkbeelden enzovoorts.

Ik blijf erbij. Het is een Godswonder dat grote bedrijven nog zo goed functioneren als dat ze doen. Mensen klagen altijd over de overheid, maar bij grote bedrijven is het allemaal net zo erg. Alleen is de overheid vanuit wetgeving verplicht openbaar te maken wat er allemaal mis gaat. Bedrijven houden hun mond. Dit geeft een vertekend beeld.
Vast een domme vraag, maar dan heeft zo'n bank niet alleen 'geen broncode', maar ook geen spec en dus naar ik aanneem geen unit tests?
Wat ik heb meegemaakt, waren dat puur functionele tests, men zag dus eigenlijk niet wat er onder de 'motorkap' gebeurde. De technische tests werden door de leverancier uitgevoerd en die werden op hun mooie blauwe ogen vertrouwd... Totdat het natuurlijk keer op keer mis ging en je eigenlijk van leverancier/softwarehuis wil wisselen, maar dat niet kan omdat effectief je core applicatie wordt gegijzeld...
Komt dat dan niet ongeveer neer op reverse engineering?
Dat meerdere keren moeten doen om problemen te achterhalen nadat de leverancier al meerdere keren heeft aangegeven dat 'er is niets mis met onze software, we hebben het uitgezocht'... Dan ga je uit frustratie en noodzaak dingen uitzoeken die ver buiten je eigen taakgebied liggen.
Het probleem van dit soort projecten zit meestal net bij de “pure” IT-ers, die de neiging hebben complexiteit te onderschatten en migraties teveel als een puur technisch traject te zien, en uitgebreide testen “saai” en onnodig vinden. Je hebt bij dit soort projecten vooral erg ervaren project/programma managers nodig die de klappen van de zweep kennen.
Moet zeggen dat dit nooit mijn voorkeur heeft.. dergelijke grote wijzigingen doen wij altijd met A/B testen waar we steeds verder uitrollen.. zo beperk je de impact enorm tot een klein clubje en kan je stelselmatig zien of je landschap t houdt.

Dit soort projecten big/bang doen is haast onmogelijk omdat je dan ook goede performance tests moet hebben.. Gefaseerd uitrollen is dan vaak praktischer omdat je kan zien aankomen dat het begint te kraken waarop je kan inspelen..

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True