[dead]
Engineering principles for building financial systems
41–50 of 112 posts
Re: Engineering principles for building financial systems
#42> 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…
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…
Luckily javascript has bigint now, so you can do this stuff safely in js now (just don't do it in the frontend ever, because you cannot trust the frontend).
Re: Engineering principles for building financial systems
#43Regarding 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…
If you have a decimal then you should store it as a Decimal type, not a float nor an int. This is why Decimal types exist - the fact that most programming languages don't have a native Decimal type baffles me.
Re: Engineering principles for building financial systems
#44> 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…
> 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 easier to use UTC time zone.
Re: Engineering principles for building financial systems
#45> 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…
In Java, the original date/times were awful in the base library. Eventually, a very good replacement appeared called Joda-Time. Eventually, a "fix-all-the-design-flaws" 2.0 version was officially added to the base library as part of JSR-310. Excluding leap seconds (for which I have no practical need), I have never once found something that it cannot handle -- no matter how complex my conversion and calculation needs. A few other languages have basically ported Joda-Time or JSR-310 into their own. In 2024, date/time math feels like a hard, but solved problem with the correct libraries.
And last: I really like your example about Ruritania and the 48 cancellation policy. Sure, the country name is intended as a joke, but in the Real World all kinds of crazy things like this. Even Islamic calendars can be quite complex in 2024 -- knowing what days will be holidays in the future is a non-trivial task.
Re: Engineering principles for building financial systems
#46Earlier 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…
> Is there any financial system, regime, or product that depends upon leap seconds? I have never heard of any.
They’re certainly unusual.
> If so, it is safe to ignore them.
Really? Leap seconds have happened, and they could plausibly happen again. If so, during those leap seconds, events will occur. Do you need to record the time of those events?
> 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.
That covers most bases for past events. It is inappropriate for many future events.
Hmm, maybe a good system library would have separate types for timestamps that were actually observed (or interpolated or otherwise computed after the fact, etc) and for times of events that may not have occurred at the time of computation.
Re: Engineering principles for building financial systems
#47> 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…
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.
Ref: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: Engineering principles for building financial systems
#48We'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.…
What is the meaning of "high finance"?
Re: Engineering principles for building financial systems
#49We'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.…
The best systems that I have ever seen have two parts: (a) a read/write relational database (w/SQL) to persist data and (b) a read-only OLAP cube. With enough time, your powerusers will create the most insane reports imaginable using the OLAP cube view.
Re: Engineering principles for building financial systems
#50Mostly agree though the concept of materiality seems out of place here.
Decision making factors that in sure but system design absolutely shouldn’t. There is no reason why accounting systems can’t be accurate down to the penny. That’s what computers are good at after all.
Only place where I could see system like relevance is in presentation- showing revenue on millions etc