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

161–170 of 234 posts

Re: Fintech Engineering Handbook

#161

Post by quibono »

worik wrote: post #154
quibono wrote: post #150

Earlier quoted context omitted.

I love how this sensible take is followed by a tornado of comments that boils down to "NEVER use floats JUST BECAUSE".

Never use floats for financial calculations. Because hard won experience. "Floats" are simulations of Real Numbers, and Reals are uncountable. Not what you want for finance, where everything is counted.

I suggest reading the comment I was replying to since it contextualises the answer quite well. Hard to find absolutes in real life outside of thermodynamics.

Re: Fintech Engineering Handbook

#162

Post by krackers »

morpheuskafka wrote: post #75

A Plaid balance check is NOT a guarantee that the ACH debit you're about to submit will go through. I don't care if the balance is one million, before that ACH can process, every single dollar can be (a) wired out, (b) cleared out by yesterday's ACHs (bills, autopay, whatever) and checks, or (c) spent at debit/ATM. I probably shouldn't tell you why I know that some fintechs don't address this.

I think this is covered by the "overdraft" section, if the only way to know for sure is to just submit it.

Re: Fintech Engineering Handbook

#163

Post by zackwu »

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…

Fintech/finance is a very big industry and there are a lot of sub-domains. A HFT system programmer thinks about how to colocate their prod machines in NYSE and use zero alloc techniques to ingest marketdata as fast as possible, while a crypto wallet app developer spend more time designing cool UI to attract users and working out all the L1/L2 quirks. And I'm sure they have very different answers to whether to use integers and how many digits to preserve

Re: Fintech Engineering Handbook

#164

Post by Maxatar »

worik wrote: post #157
Maxatar wrote: post #127

Earlier quoted context omitted.

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.

> There are pretty trivial ways to use binary floating point values that don't result in 0.1 + 0.2 producing 0.30000...4 Not across all architectures and operating systems there are not Listen to those who have done this. Use integers for finance.

Yes across all architectures and OS's that use IEEE 754 floating points.

Re: Fintech Engineering Handbook

#165

Post by ViscountPenguin »

oddthink wrote: post #144
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…

> 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). That really overstates the issue. Whole domains of finance run just fine on doubles. If you're doing Monte Car…

It can be really frustrating viewing threads like this sometimes. I've not once seen an interest rate swap priced in anything other than float/double, and that's relatively simple even compared to some of the crazy instruments out there.

Like, sure, probably don't use floats for everything, but what are the odds that your greeks are gonna be nicely expressable as simple rationals?

Re: Fintech Engineering Handbook

#166

Post by Maxatar »

lxgr wrote: post #151
Maxatar wrote: post #114

Earlier quoted context omitted.

What exactly do you think a floating point number is?

Usually that, but in binary, which causes lots of headaches for financial math.

For those who don't understand what they're doing, yes. But those people end up having headaches and causing trouble no matter what.

Re: Fintech Engineering Handbook

#167

Post by Erem »

fragmede wrote: post #129
dahart wrote: post #103

Earlier quoted context omitted.

> 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 crypt…

If you render a number using JavaScript it has been temporarily stored as a doublr. The article was likely allowing for that common use case.

Re: Fintech Engineering Handbook

#169

Post by foobarian »

dgunay wrote: post #148
lawlorino wrote: post #72

Earlier quoted context omitted.

> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t). In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?

All of the data we control (in the database, in our apis, etc) is integer cents. When we have to interface with a system that represents money using JSON numbers as dollars.cents, we parse or serialize it into an arbitrary precision decimal type. Hasn't been much of a problem.

This started out fine for us except that int32s were a bad idea and upgrading was painful

Re: Fintech Engineering Handbook

#170

Post by Onavo »

oddthink wrote: post #144
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…

> 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). That really overstates the issue. Whole domains of finance run just fine on doubles. If you're doing Monte Car…

It doesn't matter for quant finance to use floats because approximate is perfectly fine. Tracking the exact amount to accounting standards is the job of the brokerage team not the quant devs. Floats are fine for modeling as long as the numerical drift is accounted for.
Post reply on HN