Electronic bank statements: Paving the way to better AI


  • Trolleybus Mechanic

    Office automation is the name of the game for a lot of the dev stuff I do at work. One such (ongoing) project is importing electronic bank statements into our accounting software.

    One would think that electronic bank statements is a problem we'd solved back in the days of COBOL. There's even a standard format for it - the SWIFT MT940.

    It is so standard, in fact, that every bank has its own distinct flavour. Presuming they offer it at all, naturally...

    Luckily, this is exactly the problem OOP was meant to solve. A simple application of inheritance and the strategy pattern lets me knock out a new parsing module for each new-and-completely-incompatible format that our clients bring in within a couple of hours of getting a sample file. After that it (usually) just works.

    Those banks that don't do MT940 usually serve up some kind of CSV - which is fine by me. In a lot of ways, parsing CSV files is even easier than the MT940s.

    Last week, however, a client brought a bunch of CSV files from a certain French bank that shall remain unnamed to protect the guilty...

    Yer bog-standard CSV statement lays out the data in a nice tabular format which makes it easy for machines to read. Here, the jokers thought it would be an excellent idea for every possible type of transaction (of which there is an unspecified number) to have its own, variable-field, record. Most of the aforementioned fields consist of "label"-"value" pairs.

    In order to make sense of this data, I had to whip up a decision engine that examines the transaction description field and determines what the order of fields will be for that particular record.

    Oh, did I mention that sometimes the description includes misspelt words?

    If my little bank account parser ever destroys the human race in a nuclear inferno, I just want you to know: I'm so sorry!


  • I survived the hour long Uno hand

    @GOG said in Electronic bank statements: Paving the way to better AI:

    If my little bank account parser ever destroys the human race in a nuclear inferno, I just want you to know: I'm so sorry!

    It sounds like we'd deserve it. Good god.


  • Impossible Mission - B

    @GOG said in Electronic bank statements: Paving the way to better AI:

    a certain French bank that shall remain unnamed to protect the guilty...

    Name and shame plx


  • Trolleybus Mechanic

    @masonwheeler said in Electronic bank statements: Paving the way to better AI:

    Name and shame plx

    I do try and maintain a veneer of confidentiality, so no. However, the acronym of their name could suggest they are based in California.

    Let that be today's riddle.


  • Impossible Mission - B

    Heh...

    Also about once a year, I get a letter from a lawyer, every year a different lawyer, at a company--I don't want to embarrass the company by saying their name, so I'll just say their initials: I. B. M.--saying that they want to use something I wrote.

    -- Douglas Crockford


  • Banned

    @GOG Now I know what bank to avoid. Thanks!

    As if others are any better....


  • Trolleybus Mechanic

    @Gąska Based on my knowledge, there are better reasons to avoid them than this little bit of bullshittery.


  • Banned

    @GOG Quality of data format is usually a good indicator of quality of software built around it. And using poor quality online banking application isn't a good idea...



  • @GOG I'm a client of that bank . . . but I've never looked at their CSV extracts, since their OFX files don't have any problem! The OFX files of one of their competitors, on the other hand, say that my balance is always zero, which is never the case (negative, sometimes, but never exactly zero).



  • ... along with better phishing scams better Spanish Prisoner cons, better man-in-the-middle attacks... and they still are more secure, more reliable and more convenient than printed statements. It's a crazy world.


Log in to reply