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

211–220 of 234 posts

Re: Fintech Engineering Handbook

#211

Post by FabHK »

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?

TFA, in Appendix A: Resources, lists many.

Re: Fintech Engineering Handbook

#212

Post by FabHK »

mhh__ wrote: post #48
koliber wrote: post #39

Anyone know of resources like this but for capital markets? Things that would allow engineers new to trading equities, options, FX, bonds, and commodities to learn about different flows, market structure, common architectures, and other things that normally you learn from years of experience.

Equities and (listed) commodities are relatively easy to get a handle on but it genuinely takes months / years even at the frontline to understand how fixed income and FX works because its still almost entirely an OTC market. There is more central clearing than ever before but e.g. if I (say) buy a bond, fund it using a repo, swap my loot back some other currency, quite a lot of this could easily still be relying on…

Even with equities, things are not entirely trivial.

A few examples: Some stocks trade in one currency, but pay dividends in a different currency. Some stocks go ex-div before the dividend amount has been determined (e.g. in Japan). Stocks trade on certain days, and trades settle on certain days, and they might be subject to different holiday calendars. Corporate actions are not entirely trivial, either (with rights issues, you need to issue two temporary securities for accounting purposes, etc.).

Re: Fintech Engineering Handbook

#213

Post by trixn »

FabHK wrote: post #209
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.

Fair enough, just wanted to point out that banks originate money as part of the lending process. You could maybe call that "money out of asset purchases" whatever that means and yes its a valid balance sheet operation. I guess you would agree that a bank needs no prior savings or deposits in order to make a loan, i.e. it doesn't need to have money that it "lends out"?

Or let me ask you this: What would in your opinion be a valid example of "money out of nowhere"?

Re: Fintech Engineering Handbook

#214

Post by fauigerzigerk »

FabHK wrote: post #206
m00x wrote: post #128

Earlier quoted context omitted.

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.

But the price of some unit of a commodity may well be expressed in smaller fractions to allow for small price changes.

You could argue that a price is not really an amount that anyone can actually pay and that's true. But it seems complex and error prone to store unit prices and amounts using different scaling factors.

Re: Fintech Engineering Handbook

#215

Post by Maxatar »

FabHK wrote: post #205
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.

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

By not thinking in terms of strict rules and dogmas and instead focusing on the actual problem you want to solve.

If you want to guarantee that adding cents together results in an exact value without any loss of precision, and you also want a tiny memory footprint and very high performance, then use a binary floating point to represent cents, just as you would use an int.

Also the question of how it's better depends on your use case and my argument is not that one representation is universally better than another, it's that money is used for such a diverse range of use cases that you need to actually understand what you're doing, what the goal is, what the potential issues are etc... in order to pick the right representation for your use case. At my trading firm we have three different Money classes optimized for three different use-cases (with functions to allow interoperability between them).

For the use case where the representation needs to use little memory, is fast, and needs to be used to perform complex financial calculations at an enormous scale, then you use binary floating point where a value of 1.0d = 0.000001 dollars. This gives you exact precision when working with cents, and lets you perform all of the usual financial computations that most quantitative applications need to perform with excellent performance.

We also have a use case optimized for I/O, where no calculations are expected to be performed but the data will be transmitted over a network or to/from a database etc...

If this isn't your domain, maybe you're just writing a GUI application/web app, then by all means use a big decimal or use an integer... I don't know, but it's very sad seeing how many people who are presumably professionals don't take just the bare minimum amount of time to think things through and instead just reason in terms of strict dogmas.

Re: Fintech Engineering Handbook

#216

Post by lxgr »

worik wrote: post #155
zdragnar wrote: post #102

Earlier quoted context omitted.

> JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec. I think that's the problem they were trying to describe. Without a formal spec, systems won't agree on how to handle floats. JS engines treat numbers as 53 bit signed floats, so passing a well defined decimal there through JSON means losing precision at the edges. Money stored in integers gets around the issue…

> JS engines treat numbers as 53 bit signed floats Please do not use Javascript for finance applications. Just do not do it Save it for user interface elements and dancing whizzimagigs, where it will do less harm.

Financial applications need user interface elements too, and doing these poorly has caused quite some [1] harm in the past...

[1] https://financialregulation.linklaters.com/post/102j8af/the-...

Re: Fintech Engineering Handbook

#217

Post by lxgr »

Maxatar wrote: post #215
FabHK wrote: post #205

Earlier quoted context omitted.

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

By not thinking in terms of strict rules and dogmas and instead focusing on the actual problem you want to solve. If you want to guarantee that adding cents together results in an exact value without any loss of precision, and you also want a tiny memory footprint and very high performance, then use a binary floating point to represent cents, just as you would use an int. Also the question of how it's better depends…

> you use binary floating point where a value of 1.0d = 0.000001 dollars

Is that actually better than just defining one dollar as 1.0? In my (pretty limited) understanding of floats, this doesn't seem to add any precision or prevent any edge cases.

Re: Fintech Engineering Handbook

#218

Post by nly »

fauigerzigerk wrote: post #188
xlii wrote: post #186

Earlier quoted context omitted.

Quick browse over Stripe API (i.e. not a simplistic payment provider) will show exactly otherwise. Metrics/durations/convexity/vega aren't monetary value, these are calculation values and I'm fine with them being whatever. If you're calculating averages to make decisions based on this I don't care if you're counting dolars or tomatoes. Monetary value is $4.50 and it's representation of actual money passed through sys…

What's your preferred solution to dealing with FX conversions? My issue with using integers everywhere is that FX conversions (or other rates) always come into play, and at that point I'm forced to use something else anyway (e.g. arbitrary precision decimals).

I worked on a trading system dealing with transaction limits expressed in USD but trading in many currencies.

FX rates and prices were expressed in fixed point because it was more efficient to handle in FPGA. A lot of thought went in to making the system accurate enough based on real FX rates while falling on the right side of the limit

Re: Fintech Engineering Handbook

#219

Post by Maxatar »

lxgr wrote: post #217
Maxatar wrote: post #215

Earlier quoted context omitted.

By not thinking in terms of strict rules and dogmas and instead focusing on the actual problem you want to solve. If you want to guarantee that adding cents together results in an exact value without any loss of precision, and you also want a tiny memory footprint and very high performance, then use a binary floating point to represent cents, just as you would use an int. Also the question of how it's better depends…

> you use binary floating point where a value of 1.0d = 0.000001 dollars Is that actually better than just defining one dollar as 1.0? In my (pretty limited) understanding of floats, this doesn't seem to add any precision or prevent any edge cases.

Depends on your use case, once again. If your use case requires that arithmetic involving cents is exact, then yes defining 1.0d = 1 cent guarantees that, just as using the int value 1 = 1 cent guarantees that. Floating point numbers can represent and perform exact arithmetic on integer values, no loss of precision.

The original example was being concerned that 10 cents plus 20 cents should equal 30 cents exactly, not 30.000000...2 cents. Well if you set 1.0d = 1 cent, you get that exact result. In fact for any arithmetic performed on values greater than or equal to 1 cent, you are guaranteed to get exact results just like you get exact results using an int to represent cents.

Now if your use case does not require exact arithmetic on cents, then by all means stick to using 1.0d = 1 dollar. Evaluate your use case and decide on an appropriate scale to use by default.

Where the benefit of floating point kicks in, for certain use cases, is that you can continue to use the same representation with operations that don't work well with fixed precision, like interest rate calculations, financial derivatives, or more advanced financial modelling techniques and you get these operations at significant orders of magnitude faster than you would using decimal representations.

And I'm not talking like 20% faster or 50% faster... the difference between using a binary floating point representation versus decimal ranges from 10x to 100x, and the difference between using a double versus a big decimal is on the order of 1000x.

In order words, a financial report that can be generated in 1 second using binary floats can end up taking almost 2 minutes using a decimal representation, and 16 minutes using a big decimal.

Re: Fintech Engineering Handbook

#220

Post by DetroitThrow »

lxgr wrote: post #71
DetroitThrow wrote: post #45

Earlier quoted context omitted.

Agree with this, working from HFT to payments to account management in the past. You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.

Big decimals are widely available and don’t require any expertise but avoid many of the footguns of implied decimal integers.

When performance isn't a concern, I largely agree! Not every financial system can use big decimal as their base, though, too. And HFT isn't the only place in the financial sector where this performance concern might pop up.
Post reply on HN