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

141–150 of 234 posts

Re: Fintech Engineering Handbook

#141

Post by jyounker »

amluto wrote: post #131
antonymoose wrote: post #121

Earlier quoted context omitted.

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.

> You store the sums on either end, the currencies, the exchange rate and the final sum? There is a remarkable amount of disagreement as to whether one should do one’s back office work based on the price or based on the quantity of the counter currency. > No one has .0000145 cents in their account. Rounding occurs in the real world. Indeed. But you either need to convince all parties to agree to round the same way or…

My experience in consumer banking says that every instrument specifies the precision of the calculation, how and when rounding happens, and slew of little details.

So, yes, everyone has to understand how all their partners are doing rounding and summing.

Re: Fintech Engineering Handbook

#142

Post by jyounker »

m00x wrote: post #136
gib444 wrote: post #108

Earlier quoted context omitted.

Native English speaker. I scanned it and IMO there's a slight overuse/misuse of hyphens. Maybe the AI tool could be asked to identify and correct? (The hyphens might be triggering people to think it's AI, too). They mostly need replacing with a full stop or a colon. E.g. "In practice this means storing the amount as an integer in its smallest unit - €12.34 becomes 1234" -> "In practice, this means storing the amount…

Hyphens here are meant to be formatting. You would be correct if this was a literary piece, but handbooks and sheets don't need to use these rules.

It's a misuse because in this context the hyphen could be mis-construed as a negative amount, and this causes the reader to stop and carefully re-read the content to ensure that they're not misinterpreting it. That's not where you want to be spending your reader's attention.

Re: Fintech Engineering Handbook

#144

Post by oddthink »

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 Carlo options pricing over interest rate paths, and 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. How are you going to force `exp(-rt)cashflow` to be an integer? Or the normal CDF?

Yes, there are domains where ints make sense. But it's certainly not universal, you just need to make the right engineering choice.

Re: Fintech Engineering Handbook

#145

Post by fvdessen »

The whole avoid floats thing just isn't true. I have 20years experience in fintech and most of it used doubles. Excel uses doubles. Your frontend will use doubles. All your db supports doubles. Your stdlib knows how to parse doubles. Json uses doubles (not in theory but in practice). Many ERP system uses doubles

The thing for working with currency with doubles is that you have to keep in mind that it can hold 15 digits of precision in total. As long as your numbers don't use more digits than that, like 123456789.01 or 123.456789, you can have perfect decimal precision in your financial math. You just have to always round the result to within 15 digits of precision after each computation, and before each comparison. That's what excel does.

The biggest advantage of doubles is that 1) they're widely supported and 2) you can mix different precision in your system, which will appear if you do international finance or advanced financial products. Some accounting require precision up to the thousandth, some need to be rounded to multiples of 0.25. So at the end of the day you'll never use basic math but some specialised accounting math library and that library can perfectly use float as a backend.

Re: Fintech Engineering Handbook

#146

Post by Scubabear68 »

lxgr wrote: post #97
traceroute66 wrote: post #91

Earlier quoted context omitted.

> What if you're the employer ("first engineer" etc.), and there are no practices yet? In that scenario the practices will still come first. You're not going to be doing any coding or systems engineering until you've got compliance signed off. You're going to be spending lots of time with lawyers and compliance people. > Fintech almost by definition sometimes includes doing things from scratch Yes, but cut through th…

Please show me the regulation that tells me whether to use big decimals or integers in my internal monetary amount representation. Regulations usually care about outcomes (sometimes high, sometimes low level); they often don't tell you how to technically achieve them. And if your lawyers and compliance people are actually telling you that you can absolutely not do any financial processing yourself, that the only poss…

This sounds great until your counterparties, banks, the government, customers and others complain bitterly that your monetary amounts are off.

Your expectations of course are not unusual because so many developers work on systems where users are not the customers, but the product.

Facebook, Insta, Google all fuck up results very regularly, but what are you gonna do when they do?

Now imagine your bank occasionally losing deposits, your account balance going up and down a percent or two every day, the IRS fining you for tax evasion because your Cool Fintech Rounding does not match generally accepted accounting rules.

Re: Fintech Engineering Handbook

#147

Post by solomonb »

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.

The integer `1` can mean whatever you want, it doesn't need to be a cent. Haskell's `Fixed` type is a good example of this:

https://hackage-content.haskell.org/package/base-4.22.0.0/do...

Its a wrapper around an `Integer` where you declare the scale in the type. So if you use `Fixed E2` as your type then `MkFixed 1` is 1 cent. If you did `Fixed E3` as your type then `MkFixed 1` is 0.1 cent. In both cases it is entirely an integer encoding.

Re: Fintech Engineering Handbook

#148

Post by dgunay »

lawlorino wrote: post #72
lxgr wrote: post #69

Earlier quoted context omitted.

> thank you Rust decimals represented as JSON floats What do you mean? JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec. > If I ever see a monetary value stored in something else than integers I'm going to run away screaming That’s good, then we’ll likely not be working on the same system :) I consider running from “amounts as integer” systems these days (but u…

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

Re: Fintech Engineering Handbook

#149

Post by lxgr »

jyounker wrote: post #140
lxgr wrote: post #94

Earlier quoted context omitted.

Yes, definitely always include the number of digits, but at your system boundary you still have to pray that whoever you're working with isn't silently dropping that number and re-deriving it from their own, almost-4217-compliant currency database. Redundancy can be great, but it's not a panacea, since it's not guaranteed to be used in an optimal way.

How you expose you present your data to third parties is not how you represent it internally.

Ideally it’s not, but I’ve seen it leak so often that I’d rather be safe than sorry.

Re: Fintech Engineering Handbook

#150

Post by quibono »

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…

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