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

81–90 of 112 posts

Re: Engineering principles for building financial systems

#81

Post by yareally »

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…

Only a guess, but maybe financial markets that run 23 hours a day, 6 days a week, such as futures?

Re: Engineering principles for building financial systems

#82

Post by cgio »

jwarden wrote: post #71
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…

There’s a difference between a point in physical time, and a coordinate on a calendar. UTC works great for points in time, both past and future. So UTC is very appropriate for logging, including of financial transactions, where often what matters is the exact point in time something happens and not how that maps to someone’s calendar or the time zone on a server. But UTC doesn’t work at all for a calendar app, where…

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

Re: Engineering principles for building financial systems

#83

Post by zoover2020 »

withinboredom wrote: post #73
HWR_14 wrote: post #60

Earlier quoted context omitted.

> This suited me down to the ground because I pointed out to everybody that Javascript couldn't be guaranteed to treat numbers and calculations in a way that would keep the regulators auditors happy, Javascript can represent dollar values up to $2.25 billion at a resolution of ten-thousandths of a cent without any loss of precision. I would want all money calculations done by the backend team as a matter of policy. B…

While you are correct that it can _represent_ these numbers with that precision... it cannot operate on them and retain that precision, so DO NOT USE FLOATS TO REPRESENT MONEY. Thank you for your time. let a = 35 let b = -34.99 console.log(a+b) // output: 0.00999999999999801

Brr almost got the shivers until I read your comment

Re: Engineering principles for building financial systems

#84

Post by amelius »

Terr_ wrote: post #3

> Use consistent rounding methodologies This may also mean promoting them to a named part of the business-domain in code, with their own functions, unit-tests, stuff like "fetch Rounding Strategy Suite by country code", etc. > Use integer representations of time. This one is a little controversial but I stand by it. There are so many libraries in different technologies that parse timestamps into objects, and they all…

> but you don't reeeeealy know how many seconds from now that will happen

So don't use a time-like object. Instead use a condition.

Re: Engineering principles for building financial systems

#86

Post by makeitdouble »

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?

That's usually how it's done in systems using int as well: internal calculations are done with as much precision as needed, and only the significant results are converted back to int using a defined rounding strategy.

Re: Engineering principles for building financial systems

#87

Post by jakjak123 »

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, but also our accountants kept asking for the craziest of things. I guess its a problem that the real world of transactions is full of async processes and weirdness. There is always something new weird that will happen, so it always ends up back in a spreadsheet software.

Re: Engineering principles for building financial systems

#88

Post by xbar »

dmoy wrote: post #54
ibejoeb wrote: post #51

Earlier quoted context omitted.

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…

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.

Re: Engineering principles for building financial systems

#89

Post by sroussey »

cgio wrote: post #82
jwarden wrote: post #71

Earlier quoted context omitted.

There’s a difference between a point in physical time, and a coordinate on a calendar. UTC works great for points in time, both past and future. So UTC is very appropriate for logging, including of financial transactions, where often what matters is the exact point in time something happens and not how that maps to someone’s calendar or the time zone on a server. But UTC doesn’t work at all for a calendar app, where…

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?
Post reply on HN