Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering principles for building financial systems

substack.wasteman.codes

Post reply on HN
Print view View original

31–40 of 112 posts

Re: Engineering principles for building financial systems

#31

Post by tumetab1 »

ibejoeb wrote: post #29

We're basically talking about bookkeeping systems here, rather than high finance. Use a good relational database. 1. ACID, so you don't have to invent it. 2. Arbitrary precision numeric data types with vetted operations and rounding modes. 3. It does time as well as anyone can 4. Your computations and reporting can be done entirely in SQL. 5. When you get good at SQL or hire someone who is, the reporting is elegant.…

> 2. Arbitrary precision numeric data types with vetted operations and rounding modes.

Be aware that a good rationale for choosing the database but you should enforce a specific precision per table otherwise you can get nasty accounting bugs because you're adding a 3.0095 amount with an 9.99 amount.

Re: Engineering principles for building financial systems

#32

Post by ibejoeb »

tumetab1 wrote: post #31
ibejoeb wrote: post #29

We're basically talking about bookkeeping systems here, rather than high finance. Use a good relational database. 1. ACID, so you don't have to invent it. 2. Arbitrary precision numeric data types with vetted operations and rounding modes. 3. It does time as well as anyone can 4. Your computations and reporting can be done entirely in SQL. 5. When you get good at SQL or hire someone who is, the reporting is elegant.…

> 2. Arbitrary precision numeric data types with vetted operations and rounding modes. Be aware that a good rationale for choosing the database but you should enforce a specific precision per table otherwise you can get nasty accounting bugs because you're adding a 3.0095 amount with an 9.99 amount.

Yes. The data type itself supports arbitrary precision. I'm not suggesting that you chose the precision arbitrarily.

Re: Engineering principles for building financial systems

#33

Post by ibejoeb »

gushogg-blake wrote: post #30

Regarding the types, I think it's easy to fall into the trap of thinking you have to try and force the domain concept into one of the commonly available data structures at the point of creation, i.e. the price "£3.99" has to become (int) 399 or (float) 3.99000000001. Actually, as another commentor mentioned, you can and should just choose something that represents what you want. In many cases it will be an object wit…

The string "3.99" always comes back as a string, but when you need do anything at all to it, it resolves down to the same problem.

Re: Engineering principles for building financial systems

#34

Post by openrisk »

JetSetIlly wrote: post #5

Good summary but the article doesn't mention the engineering of the user interface. In this field of accountancy, I think the UI is an engineering problem at least as important as anything else mentioned in the article. As someone who works in accountancy (as a bookkeeper/accountant) I have to be brutally honest and say that I've been very disappointed in the UI of all the accounting software packages I've used. None…

> I think the UI is an engineering problem at least as important as anything else mentioned in the article.

Indeed.

> I'm not sure what a good solution would look like

What is interesting is that on the business reporting side (which is in any case deeply enmeshed with the accounting system side) there is a defacto standard (xbrl and its various specifications [1]) which via web technologies (iXBRL [2]) provides a path towards generic web UI patterns.

[1] https://www.xbrl.org/int/gl/2016-12-01/gl-framework-2017-PWD...

[2] https://www.xbrl.org/the-standard/what/ixbrl/

Re: Engineering principles for building financial systems

#35

Post by langcss »

ibejoeb wrote: post #33
gushogg-blake wrote: post #30

Regarding the types, I think it's easy to fall into the trap of thinking you have to try and force the domain concept into one of the commonly available data structures at the point of creation, i.e. the price "£3.99" has to become (int) 399 or (float) 3.99000000001. Actually, as another commentor mentioned, you can and should just choose something that represents what you want. In many cases it will be an object wit…

The string "3.99" always comes back as a string, but when you need do anything at all to it, it resolves down to the same problem.

Ideally, one should make illegal state unrepresentable. The problem with a string is there is no guarantee it represents a money amount.

Re: Engineering principles for building financial systems

#36

Post by pintxo »

JetSetIlly wrote: post #5

Good summary but the article doesn't mention the engineering of the user interface. In this field of accountancy, I think the UI is an engineering problem at least as important as anything else mentioned in the article. As someone who works in accountancy (as a bookkeeper/accountant) I have to be brutally honest and say that I've been very disappointed in the UI of all the accounting software packages I've used. None…

I agree.

While I managed our start ups finances, I so much preferred to stay doing everything in Excel over having to use our accountants system. And I get a glimpse into SAP from time to time as my wive is an accountant. It's incredible how shitty those systems are from the user perspective.

But I guess, this is what you get when the user is not also the customer.

Re: Engineering principles for building financial systems

#38

Post by [deleted] »

ibejoeb wrote: post #29

We're basically talking about bookkeeping systems here, rather than high finance. Use a good relational database. 1. ACID, so you don't have to invent it. 2. Arbitrary precision numeric data types with vetted operations and rounding modes. 3. It does time as well as anyone can 4. Your computations and reporting can be done entirely in SQL. 5. When you get good at SQL or hire someone who is, the reporting is elegant.…

[deleted]

Re: Engineering principles for building financial systems

#39

Post by Galanwe »

tomnipotent wrote: post #16
Galanwe wrote: post #4

I wouldn't endorse many of the things stated there. A lot of the points are inaccurate or straight up misleading. > The three main goals of your accounting system are to be (1) Accurate, (2) Auditable and (3) Timely. You forgot "consistent", which is very different from "accurate". Most financial transactions have multiple time dimensions: a trade is requested, booked, filled, matched, reconciliated, paid, settled at…

> You forgot "consistent" I once had an auditor tell me that the books are allowed to be wrong, but should be wrong consistently. I've even run into the timestamp issue, which generally turned out to be a non-issue unless the wrong date was used (like order date vs. shipping date for revenue recognition) or a considerable number of errors caused dates to end up in a different reporting period. If you're dates are con…

> I've never seen a reporting period closed without accountants making journal entries for manual adjustments. These can often be material changes.

The fiscal view is just one of the layers your accounting system takes into considerations.

You typically perform fiscal reconciliation when the fiscal year ends, your bookings are often reconciliated end of day, your settlements usually between 1 or 2 days (depending on the currency), your FX hedge often quarterly to enter IMM interest rate swaps, your front office is often optimistic realtime accounting (i.e. you consider what has been promised just now to already be out of the stock), etc.

> This is correct, but for internal reporting you might need to.

Right but this is more some form of Bi on top of the accounting system than part of it. For the accounting system itself, you will often want to know precisely the cash per currency so that you can actually hedge it. e.g. if you're ultimately getting paid in dollar and have exposure to some salaries you pay in euro.

Re: Engineering principles for building financial systems

#40

Post by Galanwe »

amluto wrote: post #27
Galanwe wrote: post #4

I wouldn't endorse many of the things stated there. A lot of the points are inaccurate or straight up misleading. > The three main goals of your accounting system are to be (1) Accurate, (2) Auditable and (3) Timely. You forgot "consistent", which is very different from "accurate". Most financial transactions have multiple time dimensions: a trade is requested, booked, filled, matched, reconciliated, paid, settled at…

> Most financial transactions have multiple time dimensions: a trade is requested, booked, filled, matched, reconciliated, paid, settled at different times. These times often don't even follow a perfectly logical order (you can request and fill a trade and book it an hour later). Similar issues exist with transaction identifiers. Every party involved with any aspect of a transaction may assign that aspect of the tran…

Spot on.

Worst, these identifiers can even be point-in-time. I usually store them as you do, with an additional start/end date.

Post reply on HN