Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

This is a very selective view of banking. In financial reporting you have a lot of situations where you need a consistent point-in-time snapshot of your data or you might be in very big trouble.

It's true that clearing of payments and trades is usually a multi-step process that isn't done in one huge distributed transaction. But implementing each stage of that process without ACID transactions seems like a daunting task to me.

So I think Eric Brewer's remarks lack a bit of nuance and detail, but he's not entirely wrong of course.

View on HN

Could you be specific. In what particular areas do you need a consistent point-in-time snapshot?

Having worked in finance myself, as part of a team that procured and replaced an international core banking system with a state-of-the-art, multi-hundred million dollar successor; we've never had a strong consistency requirement. Much weaker forms consistency sufficed for their needs and the requirements of regulators.

Also what big trouble do you mean? I do not know of any financial regulators that expect banks to have a totally consistent point-in-time view of their balance sheet. Furthermore the Basel Accords and similar banking supervision rules do not mandate such a requirement.

I be very much grateful if you could provide me with this information, as I can pass it to my former colleagues who will be quite surprised to discover this requirement.

That last paragraph implies you're less interested in finding out and more interested in insisting those requirements don't exist because you worked on a project that overlaps with the incredibly broad term "financial reporting". The term is so broad I'd almost say your anecdotal experience is more likely to be irrelevant than not.

A core banking system captures and stores all the transactions and business a bank performs. Without this a bank would not be able to function let alone produce a meaningful financial report.

In what way does that mean you'd be able to disprove the statement:

"In financial reporting you have a lot of situations where you need a consistent point-in-time snapshot of your data or you might be in very big trouble."

You're trying to sell your anecdotal experience rather than explain your point.

A long time ago I was part of a team that was supposed to create a new core banking system. The project emerged from an earlier attempt to remodel the entire IT of a smallish European investment bank.

Some of my coworkers were still involved with that previous remodelling work, which was based on an extremely weird 1980s/90s RAD tool + database combination (I don't remember the name). That system was lacking proper ACID semantics and they were struggling very hard to create consistent reports.

The bankers kept throwing back their reports because of inconsistencies that resulted from an inability to get a point-in-time snapshot while the system was in operation. So they tried to create those reports during the batch windows available to them, which turned out to be just barely possible after many embarrassing failures.

This will probably leave you unsatisfied because I cannot tell you exactly what was in those reports or why selecting based on a date column wasn't enough to get a consistent view. Accounting is supposed to be append only after all. I can only tell you that they were smart people struggling with the lack of ACID transactions.

I seem to remember that some reports were for the banking regulator of that country. The bankers were extremely concerned about any delays, because they feared closer scrutiny by the regulator. That's one thing I was referring to when I said "very big trouble". The other one is that the software maker's contract with the bank was apparently in jeopardy.

Reply on news.ycombinator.com