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

91–100 of 112 posts

Re: Engineering principles for building financial systems

#91

Post by RaftPeople »

woah wrote: post #58

Cryptocurrencies tend to use very large integers (128 or 256 bit) for everything throughout the system. Rounding doesn't happen until a number hits the UI. Why would you design a system that intentionally destroys data several times internally?

> Why would you design a system that intentionally destroys data several times internally?

Because it matches the requirements of the domain being modeled.

Most business to business and business to consumer transactions require that amounts are limited to some number of decimal positions (e.g. in US it's 2 decimal positions).

If you create a system document/transaction like an invoice that doesn't adhere to this rule then your software is not properly modeling the domain (i.e. it's a design flaw).

If you decided to leave it unrounded internally, then you are basically storing an incorrect value and delaying the calculation of the correct value until consumption (which is typically hundreds to thousands of consumers).

But what is the gain to storing the wrong value? Nobody wants it and it just complicates the entire system.

Re: Engineering principles for building financial systems

#92

Post by eru »

mgaunard wrote: post #69
eru wrote: post #23

Earlier quoted context omitted.

Depending on how many numbers you process, inefficiency might not matter. You could probably use arbitrary precision rational numbers (eg as implemented in Python https://docs.python.org/3/library/fractions.html ) for all your accounting needs, and it would still be fast enough.

There are millions of financial instruments and their price change 100 million times per day. That's a lot to process, so yes, it matters.

Yes, it depends on what you do.

If you want to do financial pricing of lots of instruments, performance is important.

If you want to do the accounting for one company (that is not trading in millions of financial instruments but, say, is building and selling widgets), you have far fewer numbers on your books.

Re: Engineering principles for building financial systems

#93

Post by amluto »

sroussey wrote: post #89
cgio wrote: post #82

Earlier quoted context omitted.

The mapping to someone’s calendar is important too, though, when you start looking at accruals…

And you need all the mapping rules for the past. Say, we got rid of daylight savings time starting next year. The year after that, what happens when you look at a time/date a decade before?

The IANA (“Olson”) database handles this.

Re: Engineering principles for building financial systems

#94

Post by Terr_ »

throwaway2037 wrote: post #47
bigiain wrote: post #8

Earlier quoted context omitted.

Also: > Granularity of your financial amounts should ... ... comply with relevant regulations. I worked on a gambling webapp a long time back - we were bound by government regulations on gambling licences to perform all calculations at a precision of one ten thousandth of a cent, and were only permitted to round to cents once at the very end just before displaying a dollar amount to a person. (This suited me down to…

You wrote "a long time back", so maybe my point can be ignored. Did you not consider to use decimal math? According to MDN, the largest int in Javascript is 2^53 – 1. If you steal four digits for your fraction, that still leaves a huge number. I will assume that no one was gambling more than one billion currency units, so you had plenty of space. Do all your calcs with ints, then divide by 10,000 for a final result.…

> Do all your calcs with ints

I suspect there's an important set of gotchas lurking in here around the difference between actually doing calculations with integers---which is not possible in Javascript--versus doing calculations with floating-points that happen to represent (safe) integers.

Re: Engineering principles for building financial systems

#95

Post by sgarland »

throwaway2037 wrote: post #44
amluto wrote: post #25

Earlier quoted context omitted.

> Unix timestamp, or even integer based UTC datetimes work perfectly fine. For serious work, it’s worth noting that leap seconds are not representable in this format. Many financial applications can get away without representing leap seconds, but this is fundamentally a kludge. If you actually need to represent any point in time (according to UTC or any particular timezone), use a representation that actually represe…

Is there any financial system, regime, or product that depends upon leap seconds? I have never heard of any. If so, it is safe to ignore them. When storing date/time stamps, I prefer to persist into two separate fields: (a) date/time using UTC time zone and (b) original time zone offset, e.g., UTC+8. When debugging, it is useful to know the original time zone offset. And when querying and processing data, it is easie…

That’s what the TIMESTAMPTZ type does in Postgres, albeit you have to read the offset and do the math. MySQL also allows you to specify an offset. Or for a fun kludge, store them as TIMESTAMP in MySQL (just not past 2038), and it silently casts it into UTC for storage, and then back to the server’s TZ – or whatever the connection specifies – for retrieval.

Re: Engineering principles for building financial systems

#96

Post by [deleted] »

ibejoeb wrote: post #51
throwaway2037 wrote: post #48

Earlier quoted context omitted.

What is the meaning of "high finance"?

Specialty stuff like high frequency trading, risk models, bespoke instruments, and other non-retail products. Like if you're doing HFT, you're probably rolling your own loops. But the broader point is that this piece is about accounting-related systems that don't typically deal with hard volume, speed, or latency constraints. The term "finance" can mean the corporate "finance & accounting department" but you want to…

[deleted]

Re: Engineering principles for building financial systems

#97

Post by RaftPeople »

gwright wrote: post #37

The biggest misunderstanding I see in these types of discussions is that there is a lossless conversion between binary floating point representation and decimal representation. Very few values have exact decimal and binary floating point representations.

Note: I think you meant to say "lossy" instead of "lossless"

Re: Engineering principles for building financial systems

#98

Post by dmoy »

xbar wrote: post #88
dmoy wrote: post #54

Earlier quoted context omitted.

Yea this article really should have used "accounting" instead of "finance" (or more specifically, operational accounting). Right, like, if you're a programmer going into a project-for-finance/accounting-team at your large megacorp, and don't know if this article is the right subject area, just ask the finance/accounting person about "year end close" and see if they get a thousand yard stare or not. If yes, this is th…

Most correctly: Financial Accounting.

Oh could be, either or

Guess there wasn't really anything in the article to say if it was for internal (operational) or external (financial)

Re: Engineering principles for building financial systems

#99

Post by gwright »

RaftPeople wrote: post #97
gwright wrote: post #37

The biggest misunderstanding I see in these types of discussions is that there is a lossless conversion between binary floating point representation and decimal representation. Very few values have exact decimal and binary floating point representations.

Note: I think you meant to say "lossy" instead of "lossless"

Nope. I was asserting that confusion comes from people believing that a "lossless" conversion exists. Sorry if that wasn't clear.

Re: Engineering principles for building financial systems

#100

Post by feldrim »

amluto wrote: post #93
sroussey wrote: post #89

Earlier quoted context omitted.

And you need all the mapping rules for the past. Say, we got rid of daylight savings time starting next year. The year after that, what happens when you look at a time/date a decade before?

The IANA (“Olson”) database handles this.

That handles the time "now". Assume within 3 years, a country changed timezones 2 times. If you rely on TZDB, you can never be sure "What happened on May 16.00?". It happened in Turkey and it was a bad time to be a sysadmin.
Post reply on HN