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

101–110 of 112 posts

Re: Engineering principles for building financial systems

#101

Post by dumah »

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…

Timezone, not the offset, should generally be stored.

Offsets rotate throughout the year.

If you store only the offset, you can’t necessarily apply a delta to the time and localize it to the origin locale.

Re: Engineering principles for building financial systems

#102

Post by inopinatus »

withinboredom wrote: post #74
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…

> No! Delay currency conversion _until conversion occurs_! Sometimes these are legal requirements one way or the other. In my country, invoices in other currencies are based on the ECB rate of the date of the invoice, no matter what the actual value is when converted.

That doesn’t contradict the advice; the discussion above is about the accounting entries, not the invoice. An invoice issue is a commercial event, and the amount of the invoice is the actual value of the invoice, and will be the amount debited to accounts receivable and credited to income when the accounting entries are written, and must be in the reporting currency of that entity, so a conversion does occur on that date of issue.

If a different amount is accepted later in payment, then that difference is entered as an adjustment to income, probably coded to an account with a name similar to “gains/losses due to currency fluctuations”.

Do not confuse the commercial document/event for the accounting entries. The latter is a product of the former and they explain each other. In principle the ledgers can be entirely reconstructed from the primary records of commercial activity. The distinction is made even more clear by the existence of processes that validate one from the other viz. reconciliation and audit.

The broader takeaway is that your database of commercial activity must not use the accounting entries as its primary record. In my view the only data structure these two share is the chart of accounts.

Re: Engineering principles for building financial systems

#103

Post by dennis_jeeves2 »

alphalima wrote: post #14

On the best practices, as noted by others, there are probably classes in your standard lib/ commons lib that cover this stuff better than storing in integers (e.g. BigDecimal in Java and Python Decimal have precision and rounding mode concepts built in). Something I've found valuable is on is managing euler units/ratios (e.g. proportions 10^1, percentages 10^-2, basis points 10^-4) . Enforcing a standard that all int…

Just FYI here: To the extent that I explored even BigDecimal in Java falls short when it comes to the calculations. It does do well on the rounding. There might be other libraries that are better when it comes to calculations. If those libraries don't exist integers are the way the go.

Re: Engineering principles for building financial systems

#104

Post by dennis_jeeves2 »

willtemperley wrote: post #26

> Use integers to represent financial amounts I followed this mantra when building a trading system. This was the worst engineering decision I ever made - it added complexity and runtime overhead, plus readability was reduced when debugging. If your language has a proper decimal type like BigDecimal in Java or Decimal in Swift, I'd suggest using it. They offer perfect precision for financial applications, are battle…

>BigDecimal in Java

Correct me if I'm wrong. The last I checked, BigDecimal in Java falls short when it comes to the calculations. ( very big and very small numbers). It does do well on rounding. There might be other libraries that are better when it comes to calculations. If those libraries don't exist integers are the way the go.

Re: Engineering principles for building financial systems

#105

Post by jakjak123 »

arsenico wrote: post #28
47 wrote: post #24

A great companion read is Martin Fowler’s “Accounting Patterns”[1]. Having built and maintained systems that manage financial events for over a decade, I wish I had read these patterns earlier. [1] https://martinfowler.com/apsupp/accounting.pdf

I think Fowler's work is an underrated must-read for anyone who works in domains related to moving money. Makes any kind of engineering practices and architecture principles logical and make sense.

Yes, and I was lucky enough to read his stuff on finance within 6 months of starting work! He has some very good design ideas for many things, just as always treat it like things in your toolbox and not dogma.

Re: Engineering principles for building financial systems

#106

Post by RaftPeople »

gwright wrote: post #99
RaftPeople wrote: post #97

Earlier quoted context omitted.

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.

Ok, that makes sense.

Re: Engineering principles for building financial systems

#107

Post by throwaway2037 »

HWR_14 wrote: post #59
throwaway2037 wrote: post #44

Earlier quoted context omitted.

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? According to the standard for increasing leap seconds, they interact with the opening auction of the Tokyo Stock Exchange by delaying it one second.

Source for TSE? Cursory source shows nothing.

Re: Engineering principles for building financial systems

#108

Post by throwaway2037 »

yareally wrote: post #81
throwaway2037 wrote: post #44

Earlier quoted context omitted.

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?

That is exactly why I asked. Show me a source and I will believe it.

Re: Engineering principles for building financial systems

#109

Post by yareally »

throwaway2037 wrote: post #108
yareally wrote: post #81

Earlier quoted context omitted.

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

That is exactly why I asked. Show me a source and I will believe it.

https://www.fia.org/fia/articles/fia-coordinates-industry-pr...

> "Leading up to the 2015 leap second event, there was concern within the financial industry that similar issues could lead to a disruption to trading operations across exchanges, clearinghouses, brokers, investors and key service providers. The Commodity Futures Trading Commission asked U.S. futures exchanges to provide details on how they planned to approach the leap second event. Some exchanges published plans to delay the opening of trading. Several exchanges in Asia have also announced details regarding how their systems will adjust their clocks before or after the leap second, and will retain normal trading hours."

Re: Engineering principles for building financial systems

#110

Post by funcDropShadow »

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…

No, but the representation of new year 2029 00:00 in a UTC timestamp depends on how many leap seconds happen between epoch, 1970-01-01T00:00:00, and then. If you compute the timestamp for 2029-01-01T00:00:00 UTC now, and they add another leap seconds in 2025, then your timestamp represents instead 2028-31-12T23:59:59 UTC. Depending on your business this may matter or not. Differences based on time zone changes may be even larger.
Post reply on HN