back to article Did a date calculation bug just cost hard-up Co-op Bank £110m?

A programming blunder appears to have landed the cash-strapped Co-op Bank an unexpected bill for £110m. In its financial report [PDF] for 2013, which last week revealed a £1.3bn loss, the bank said it had to stump up nine-figure "costs relating to breaches of the Consumer Credit Act". Specifically, the scandal-hit bank noted …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    Julian date

    it's there for a reason - use it !

    1. Ole Juul Silver badge

      Re: Julian date

      But they encountered the dreaded "transaction malleability" bug.

  2. John Riddoch

    So how does this work on leap years? Does this give borrowers a way to get out of paying interest on leap years?

    1. Phil W

      Why would it?

      The requirement is to send the statement within 365 days. As far as I'm aware it can be less than this (360 days for instance to ensure it is received in plenty of time). Leap years don't factor in to it.

    2. indie

      They've got that covered...

      "For this purpose, a year shall be presumed to have either 365.25 days, or 365 days for non leap years and 366 days for leap years, or 52 weeks, or 12 equal months. An equal month is presumed to have 30.41666 days (i.e. 365/12)."

  3. Longrod_von_Hugendong

    The weak link...

    is probably the fact the programmer(s) used don't use the gregorian calendar natively.

    1. Brewster's Angle Grinder Silver badge

      Re: The weak link...

      We didn't cross a centennial year, so I don't think that comes into it.

  4. John G Imrie Silver badge

    I hate writing

    and testing jobs that run once a year. You can never get a decent testing platform for them.

    1. Anonymous Bullard
      Paris Hilton

      Re: I hate writing

      yeh, it takes ages waiting for the results.

      1. Anonymous Coward
        Anonymous Coward

        Re: I hate writing

        used to run time travel environments for this kind of thing, testing customers through their contract life cycles, devs and testers could just roll the box forever forward - though we did get some very interesting errors when a user accidently set a 5 date year. This was some time ago...

  5. Anonymous Coward
    Anonymous Coward

    Most likely due to some manual portion of the process screwing up (setting the wrong date in some UI portion), and the coded part doing exactly what it should have (i.e., it worked for all the other loans that went beforehand). Easier to blame the programmer though.

    1. bpfh Bronze badge

      Probably not even automated...

      Some bloke run it last year, maybe put a recurrent reminder in their outlook to run the batch again in 360 days. They got a golden handshake, provided a binder of procedures including all the one-shot-one-off-become-recurrent-to-be-automated-one-day-when-we-have-time scripts to his replacement and that one fell threw the crack. Some manager still around had a vague memory about when the last time that was run, probably just before a bank holiday weekend, told their resident BOFH about it, who ran it a year later, after aforementionned bank holiday weekend, ergo, 3 days late...?

  6. stu 4

    code examples

    Ok boys - so about we post examples of how WE would code setting a date to current date + 365.

    To add my 2c - I'd first get the requirement defined. Do they really mean 'same time next year' and it has been defined incorrectly as 365 ? If so - just change the year to +1 and job done. Even it is WAS really +365 days if they were happy with it being 1 off, it still could be the acceptable solution.

    Julian dates... really ?

    1. Anonymous Coward
      Anonymous Coward

      Re: code examples

      Changing year to +1 is not enough if you're doing it on the last day of February on a leap year.

      1. Brewster's Angle Grinder Silver badge

        Re: code examples

        Changing year to +1 is not enough if you're doing it on the last day of February on a leap year.

        Most routines I've used will adjust it to the 1st March; both libc's mktime and javascript's Date constructor have this property.

    2. Anonymous Bullard

      Re: code examples

      I have the answer!

      // work out when the next report is due:

      next_report = add_365_days();

      Seriously, though, I'd probably do something like:

      if (days_since(last_date) == 365) {

      // send


      No, actually, this is more readable:

      if (ready_for_report()) {

      // send


      Where do I collect my prize?

      1. Anonymous Coward
        Anonymous Coward

        Re: code examples

        The Mainframe COBOL compiler might not like that code.

        1. Anonymous Coward
          Anonymous Coward

          Re: code examples

          They don't run the bank on a mainframe

      2. Martin Gregorie Silver badge

        Re: code examples

        Nope, no prize for you (or anybody else who suggested a solution) because you all forgot about weekends and other non-working days. A more correct solution would be:

        Take the day and month of the contract start date

        Add the current year to get a date in the current financial year.

        If its a working day, you're done.

        Otherwise step back a day and and check again. Keep doing this until you've found a working day.

        Then have a word with your employer's tame contract lawyers to make sure you don't need to send the statement even earlier to allow for postal delivery and/or bank processing delays.

        1. Anonymous Coward
          Anonymous Coward

          Re: code examples

          yay for working day calendars...

    3. ZanzibarRastapopulous

      Re: code examples


      Whatever language you use has libraries for this because people mess them up all the time, use the library.

      1. Anonymous Coward
        Anonymous Coward

        Re: code examples

        But sometimes the library is broken. We encountered a bug in the date functions in SCO's C library. (I can't remember whether it was OpenServer or UnixWare.)

        If you really care about correctness it's a good idea to do your own implementation and compare it with someone else's implementation, thereby perhaps finding bugs in both. Some date functions can be tested exhaustively as the number of possible inputs, or inputs that you care about, is less than a few thousand million. So take ten minutes to do that. However, none of this protects against someone misunderstanding how the function should be used.

        1. The First Dave

          Re: code examples

          If you were relying on SCO then sounds like you got off lightly!

    4. Tom 13

      Re: code examples

      Set Due Date

      Send date = due date - 14 days; (to allow for wetware screw ups including postal services)

      Next Send date = Current send Date + 365 days

      Yes the send date will walk forward some, but if it gets too early the wetware can manually reset it.

  7. gloucester


    Could be the post room.

    "Ok guys it's beer-of-clock, we'll send these on Monday."

  8. Daedalus Silver badge

    Not the programmers fault!!

    Too many companies roll out software without dry runs and offline testing. It's Co-op's fault all the way!

    1. vagabondo

      Re: Not the programmers fault!!

      > Too many companies roll out software without dry runs and offline testing.

      Could this be related to the CIO's recent departure?

  9. Len Silver badge

    I wouldn't be surprised if Excel had anything to do with it. It has at least one date (infamous leap year issue) bug that MS refuses to fix for over two decades now.

    It wouldn't be the first time that someone relying on Excel for serious calculations got bitten by it.

  10. Anonymous Coward
    Anonymous Coward

    What? Dates and times still a problem?

    1. Len Silver badge

      Re: What? Dates and times still a problem?

      The whole problem with dates and times is exactly that. Everyone thinks they understand how it works and it should therefore be easy to code.

      In reality working with times and dates is extremely complex but, because few people appreciate this complexity, things go wrong all the time. Every year there are at least one or two major stories of companies screwing up timezone offset calculations, daylight savings time switches or other unexpected date/time behaviour in their products inconveniencing millions of customers.

      I have a weekly conference call with someone in Phoenix, Arizona. Phoenix is a tough one because half the year Phoenix is in Mountain Time, the other half it's in Pacific Time. Because European and US daylight savings time switches are not aligned we have a window of a few weeks twice a year where we know the meetings in our calendars are incorrect because Exchange and Lotus Notes can't agree on what time it is where.

      Then there are places with a half timezone offset (i.e. +07:30), places that switch from one side of the dateline to the other, Israel where DST dates are a political instrument so they can change with just a few months notice, UTC and GMT not being the same although many people believe they are etc. etc.

      It's a recipe for disaster, precisely because people mistakenly think it's straightforward.

      1. Anonymous Coward
        Anonymous Coward

        Re: What? Dates and times still a problem?

        Indeed.... That's why I posted it. We've had a couple of customers (usually subject to military dictatorship - it's never fun being on site, when coup happens) who've called in and told us "the boss decreed we'd have daylight savings this year", a couple of days before the fact. It's never a laughing matter.

      2. Brewster's Angle Grinder Silver badge

        Re: What? Dates and times still a problem?

        @Len I was with you all the way until you said UTC and GMT. I thought I had a good grasp of TT vs TDT vs TDB vs TCB, UT1 vs UTC, MJD vs JD, etc... and AFAIK GMT and UTC are the same (and I've just googled). So what's the difference?

        1. Loyal Commenter Silver badge

          Re: What? Dates and times still a problem?

          In short, GMT is a time-zone, and UTC is a timekeeping system:

          1. the spectacularly refined chap

            Re: What? Dates and times still a problem?

            In short, GMT is a time-zone, and UTC is a timekeeping system:

            Err, no. GMT is the natural observed time as modified by the equation of time (hence the "mean", since it is an averaged over the year to compensate for the Earth's elliptical orbit). UT1 is basically GMT with a slightly sharpened-up definition because the original was a little vague by modern standards of precision.

            UTC is the time as determined by atomic clocks and needs leap seconds inserting periodically to keep it within 0.9 seconds of UT1. For most everyday purposes you can consider the GMT and UTC to be the same but you don't get leap seconds in GMT.

      3. Trygve

        Re: What? Dates and times still a problem?

        Phoenix, Arizona is always on Mountain Standard Time, i.e.UTC-7. This may overlap with some other adjacent timezones now and again, but Phoenix doesn't change its clocks at all.

        The complications are solely due to everyone else gyrating back and forth between daylight saving, and the idiotic decision to move the US out of sync with the DST transition in the rest of the world

        1. Len Silver badge

          Re: What? Dates and times still a problem?

          You're right that they don't change clocks. However, considering other states do change clocks they consider themselves to be on Pacific Time half of the year and on Mountain Time the other half.

          All semantics of course, but very confusing for computers nonetheless...

  11. Stevie Silver badge


    Oh please, do tell us in what language the bug was committed.

    Snuck snuck snort.

  12. Destroy All Monsters Silver badge

    "And just when Brit banking org needs £400m to stay afloat"

    I love the smell of fractional reserve banking in the morning.

  13. Anonymous Coward
    Anonymous Coward

    I wouldn't be surprised if outsourcing had something to do with it.

  14. Anonymous Coward
    Anonymous Coward

    Working with dates is hard, and financial guys believe it is not

    I've had lots of fun with finance's definition of time intervals. Mind you, a year is not always 365 days, all months don't have 30 or 31 days, four weeks is not a month, 20 working days are not always four weeks, all years don't start the first of January, etc... Mix that with such minute details such as "which day of the week is the first" (on which country?) and local/bank holidays and you have the potential to a lot of edge cases that may never be tested properly.

    Let's not even start talking about the fun of rounding dates. "At least one month outstanding" may mean many different things to different types and mixing that with financial closure calendars introduces endless WTF moments...

    1. ThomH Silver badge

      Re: Working with dates is hard, and financial guys believe it is not

      I misread 'finance' as 'fiance'. The story still sounded familiar.

  15. Anonymous Coward
    Anonymous Coward

    Did it say exactly 365 days, or no later than 365 after the previous one was sent? In either case, let's not pretend that it's rocket science by any means. And even if so, a rocket scientist would have been cheaper to hire. Co-op fail.

  16. Pete 2 Silver badge

    The immediate and the important.

    > A programming blunder ... were sent out late – specifically, 368 days after the previous annual statements

    Surely you mean a TESTING blunder: that the code (or more likely: the integrated environment in which it was run) was not put through a sufficiently realistic set of test scenarios. Or if it was, then nobody looked at the results.

    A more interesting possibility is that the code was tested AND the bug was found. But t'management thinking was: "it won't affect us for a year ... there's plenty of time to sort it out later". But somehow that never happened.

    1. Anonymous Coward
      Anonymous Coward

      Re: The immediate and the important.

      >> A programming blunder ... were sent out late – specifically, 368 days after the previous annual statements

      >Surely you mean a TESTING blunder:

      Could also be business analysis blunder too. Developer and tester could have been running off a dodgy spec.

  17. T. F. M. Reader Silver badge

    Any idea what the mistake was?

    Dates and calendars are, indeed, difficult, but how does one make a 3 day mistake? I am genuinely curious. The 365 day rule indicates that we are talking about calendar days, not business days vs. holidays, thus the problem is simpler. Anything related to leap years would cause a one day delay. Even pretending that there are 31 days in February is more likely to send the reports 3 days earlier, not 3 days later. The mind boggles...

    1. stu 4


      I'd suggest it is a batch job that runs once a week - that'd do it.

      not only that, but it's exactly the sort of crappy requirement that businesses come up with:

      - run batch job once a week on monday morning: If >364 days, send out letter.


      coded by (offshore?) monkeys that haven't the sense to ask 'er.. u sure about this ?'

      and tested by (offshore?) monkeys who blinded test on the requirements (which are clearly met).

      job done.

      1. Squander Two

        Re: @T.F.M.Reader

        Yup, a weekend with a bank holiday Monday might do it. Which would explain why only a batch of loans were affected rather than all of them. My money's on Easter, though.

    2. Tom 13

      Re: Any idea what the mistake was?

      Three days sounds like a weekend shift.

      I ran into this problem when trying to program my credit card payments in my online payment service. Nominally they are due the same day every month. Except if the day falls on the weekend. For deposits banks tend to shift to the Monday after the deposit hits. For withdrawing they shift to the Friday before the due date. So if you want to be sure your payment gets there on time, you have to shift your send date up 3 days from when you would normally send it. Even then they dick around with the due date because of the 30/31 day issue so I finally gave up and started sending based on when paychecks hit. Even at that I still have to program the three day shift account, but since paychecks are consistent (10 and 25th for me) that works.

  18. Creamy-G00dness


    Didn't I read somewhere (possibly El Reg) that the Co Op Bank had been bought by an American hedge fund group?

    Buyers remorse anyone.

  19. John Smith 19 Gold badge

    Data arithmetic is *tricky*

    But the question has to be how long has this been going on?

    This suggests a software upgrade gone titsup.

  20. 4ecks

    Hanlon's razor

    8 is above 5 on a numeric keypad, fat finger syndrome strikes again!

  21. southpacificpom


    Well we all know that if COBOL goes wrong it usually all turns to BOLOC's.

  22. Crazy Operations Guy Silver badge

    Does it have to be every 365 days?

    Couldn't they send these things out every 360 days or even just send them out monthly alongside the usually banking statements (like my bank does, but I'm a yank with a credit union, so not sure of that would comply with Brit law).

    1. J P

      Re: Does it have to be every 365 days?

      Presumably you mean "last statement +360", not "every 360 days", given that the underlying information relates to periods of 365/366 days? But yes, simply aligning the annual statements with whichever month they get produced in would appear to make sense *to anyone outside the post room* ; as previously noted, sending them before the statutory due date shouldn't be an issue.

      But large organisation mailing processes have to be seen to be believed; one of the UK's largest has a mail room 1 mile long. They have to stagger mass mailings, as Royal Mail don't have enough trucks to load all their envelopes in one go. And one day we suggested to them sending a particular notification out by manually processed recorded delivery - they don't do many of this particular item, and it was causing significant issues for the (non)recipient if it went astray. They looked at us as though someone had suggested inserting a live stoat into every envelope before despatch, and the item was minuted "for further consideration".

  23. David Cantrell

    Betteridge's Law of Headlines says that no, it wasn't a date calculation bug.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019