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

Fintech Engineering Handbook

w.pitula.me

Post reply on HN
Print view View original

121–130 of 234 posts

Re: Fintech Engineering Handbook

#121

Post by antonymoose »

amluto wrote: post #110
antonymoose wrote: post #33

Earlier quoted context omitted.

Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.

If someone sells you 12345.55 EUR vs USD at a rate of 1.12345, how many EUR do you think you end up with? Do you think all market participants even agree? What if the rate is 1.123456? For added fun, you can introduce division. Some systems will allow you to sell 12345.55 USD to buy EUR at a rate of 1.12345. The article’s “no lost data” tenet is not really viable when this sort of division is involved. Are you going…

You store the sums on either end, the currencies, the exchange rate and the final sum? No one has .0000145 cents in their account. Rounding occurs in the real world.

Re: Fintech Engineering Handbook

#122

Post by Fordec »

jdw64 wrote: post #53

As a programmer, what I feel when I see fintech programmers each speaking from their own different experiences and perspectives is that it makes me wonder what it really means to be good at programming. What user xlii said about not storing monetary amounts as floats is a common IEEE 754 issue. And while it's true that financial tracking should be done through immutable logs or event-based records, I don't think ever…

I would like to hear more about this wiki you have.

Re: Fintech Engineering Handbook

#123

Post by antonymoose »

lxgr wrote: post #64
antonymoose wrote: post #33

Earlier quoted context omitted.

Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.

If you’re only trading in USD and other two-decimal currencies it can work fine, yes. For anything else, it’s much worse as also detailed in TFA.

You provide different handling strategies for different currencies. You also sort currency data alongside your amount. There is nothing complicated or edge-case here.

This works for USD, JPY or $MEMECOIN and it scales very well.

Re: Fintech Engineering Handbook

#125

Post by cirrhosis »

sdevonoes wrote: post #28
cirrhosis wrote: post #20

I have just left a fintech company after 5 years and I can say after reading this, it looks legit to me (not AI slop as someone asked). These are the same sort of lessons I learned during my time in the industry. I would recommend anyone starting in fintech to take some time to understand accounting principles and the ledger in a bit more depth than just debits vs credits - this is likely what is most unfamiliar to p…

> I would recommend anyone starting in fintech to take some time to understand accounting principles and the ledger in a bit more depth than just debits vs credits Any good resources you would recommend to learn more about this?

I've seen a few attempts at "accounting for programmers" guides, some of which I came across while browsing HN (if you search you'll find plenty). The one I used to send new developers was one such guide[1]. They also have another on building a ledger[2]. These are a good start and I wish I could recommend a proper textbook that goes into more detail - detail that I wish I had known early on - but I learned mostly as I went along.

[1] https://www.moderntreasury.com/journal/accounting-for-develo...

[2] https://www.moderntreasury.com/journal/how-to-scale-a-ledger...

Re: Fintech Engineering Handbook

#126

Post by OtherShrezzing »

microgpt wrote: post #51
noitpmeder wrote: post #40

Earlier quoted context omitted.

The only real correct solution here is to send mantissa and exponent as two separate integers. It's trivial to convert between exponents for whatever math you want, it can be as correct as you want, and is unambiguous. In the HFT space you save some wire space if you can commit to a consistent exponent for some {slice} up front (think instrument/tick-size/asset-class/exchange/feed/server/whatever/...) such that you o…

If you do that though aren't you just reinventing floating-point?

No, standard floating point implementations have higher precision for smaller numbers than larger. So for example, in a 32bit float, there are far more numbers between 0-1 than there are between 1,000,000 and 1,000,001. For 32bit floats, you start lowing whole integers with relatively small numbers.

Integers have a consistent precision across the entire number line.

Re: Fintech Engineering Handbook

#127

Post by Maxatar »

lxgr wrote: post #120
Maxatar wrote: post #115

Earlier quoted context omitted.

But native decimal libraries are almost always floating point. Do people not know what a floating point number is?

That’s alright, the important part here is that they’re decimal, not binary. You don’t want 0.1 + 0.2 to equal 0.300…004.

There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 and it saddens me when this topic comes up and people go to such extreme lengths to recreate a second hand buggy reimplementation of a subset of floating point numbers to do it.

Re: Fintech Engineering Handbook

#128

Post by m00x »

xlii wrote: post #29

I glanced, and I found this handbook shallow and - in some areas - even bad advice. E.g. If I ever see a monetary value stored in something else than integers I'm going to run away screaming (thank you Rust decimals represented as JSON floats). It's always integers unless you have a VERY good reason to do otherwise (though exported view can be in anything, even in weird bitcoded formats). FX exchange. Resolution of F…

You can't do everything you need with an integer. There are values you might want to display or calculate with that are smaller than cents. In some places you'll need things like BigDecimal, which are immune to floating point errors in most cases.

It's also safe to return decimal values for displaying values.

Re: Fintech Engineering Handbook

#129

Post by fragmede »

dahart wrote: post #103
solumos wrote: post #101

Earlier quoted context omitted.

With integers/floats, he's saying it's not opinionated enough. Anything other than integers with minor-unit precision, unless you have a very good reason, is a bad idea. So "floating point is almost a bad idea" doesn't go far enough, and the other alternatives are presented somewhat equally. The FX critique is saying that it's glossing over a lot of the complexity. I'd say the same is true for the treatment of DE led…

> Anything other that integers with minor-unit precision, unless you have a very good reason, is a bad idea. The article clearly communicates this sentiment, no? What else needs to be said? How much further does it need to go, and why? It might be a mistake for either us or the handbook to be absolute or dogmatic about floats. It’s not a sin to mention that they exist, and it’s a fact that some people in fintech use…

"Monetary value must be stored in integers" is the much stronger statement that the article doesn't make. Obviously there are exceptions, but you're going to need a much longer side discussion in order to justify why you're using floats.

It's like saying "don't write your own crypto algorithm". Of course write your own crypto algorithm, that's how you learn about cryptography. But you'd never put your homegrown cryptographic algorithm into production until after several PhDs worth of understanding of cryptography has been put into it by many other people.

Re: Fintech Engineering Handbook

#130

Post by Maxatar »

lxgr wrote: post #88
gmm1990 wrote: post #86

Earlier quoted context omitted.

That’s quite a bit slower to process. At least if you’re converting to integers to do the calculations and the calculations would be quite a bit slower if you kept the big decimal type

True, but this is usually your least concern when you're dealing with monetary amounts/math.

It might be your least concern, and that's fine but it's not the least concern for many people who need to process large volumes of transactions.

Money, even within fintech, is a concept used across a wide variety of domains, and you can't assume that what concerns you is what concerns everyone else relying on it elsewhere.

Post reply on HN