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

201–210 of 234 posts

Re: Fintech Engineering Handbook

#201

Post by emiraga »

bayarearefugee wrote: post #153
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 Probably good advice (for everyone in fintech, not just programmers) considering the absolute disaster that happened at Synapse. Kind of wild nobody has gone to jail for that.

is there any technical article that describes shortfalls and mistakes made in Synapse?

I am curious as I had a bit of money in Yotta.

Re: Fintech Engineering Handbook

#202

Post by FabHK »

solumos wrote: post #101
dahart wrote: post #77

Earlier quoted context omitted.

What are you referring to with the integers/floats comment? The article says clearly that the rule of thumb is not to use floats and that they’re “almost never” a good idea, that they cause unpredictable precision loss, and recommends integer or BigDecimal types in multiple places. Are you also talking about rationals? So what is the bad advice here, exactly? For FX, it seems like you’re reinforcing what the handbook…

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…

> it borders on bad advice (e.g. "Balance is never stored. It’s derived from the movements of money.")

Don't think that's bad advice, in particular as the article clarifies:

> Derived state can be cached. Balances and projections can be cached or snapshotted for performance.

Of course you can cache or snapshot. But don't mistake that with storing the golden source.

Re: Fintech Engineering Handbook

#203

Post by FabHK »

Erem wrote: post #167
fragmede wrote: post #129

Earlier quoted context omitted.

"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.

[dead]

Re: Fintech Engineering Handbook

#204

Post by FabHK »

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…

> you're interested in the risk metrics, like durations, convexity, vega, and so on, no one cares what your rounding convention is. doubles are just fine, thank you.

Doubles are not just fine, but required there. If you compute risk, as you allude to, by finite differences, then you need the precision of floats rather than rounding to integer cents prematurely.

Re: Fintech Engineering Handbook

#205

Post by FabHK »

Maxatar wrote: post #127
lxgr wrote: post #120

Earlier quoted context omitted.

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.

What are those pretty trivial ways? And how are they better than storing 10 cents + 20 cents = 30 cents?

Re: Fintech Engineering Handbook

#206

Post by FabHK »

m00x wrote: post #128
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.

But it's a good idea to keep those values distinct from actual money. You can't pay a fraction of a cent to anyone.

Re: Fintech Engineering Handbook

#207

Post by FabHK »

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…

> 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?

1. If someone sells me 12345.55 EUR, I hope to end up with 12345.55 EUR.

2. That's the point though. They will sell you a certain amount of EUR at a certain dollar price. This, in turn, implies a rate (which might well have more than 5 digits behind the decimal). This is ideally close to the quoted rate, sure. But what counts is the actual EUR amount and the actual USD amount, not what rate was quoted or with how many digits.

Re: Fintech Engineering Handbook

#208

Post by FabHK »

microgpt wrote: post #52
denismenace wrote: post #10

Earlier quoted context omitted.

> but it'll bite you incredibly hard if you ever stumble upon an edge case such as working with a partner that has a different implied number of digits for a given currency Why would that be a problem? You just transform the values when interacting with their API.

Customer was charged $0.995 after fees, how to represent in your data model with integer cents?

How is the client going to pay that? They can't be charged half a cent.

Re: Fintech Engineering Handbook

#209

Post by FabHK »

trixn wrote: post #189

> Money can’t be created out of nowhere Well, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize a loan as an asset purchase as well, the bank buys a promise to pay from the borrower which is recorded as an asset of the…

Well, that's not money created out of nowhere. The balance sheet extension creates money and an equivalent liability. That's the point of the statement, not money supply and its regulation.
Post reply on HN