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

181–190 of 234 posts

Re: Fintech Engineering Handbook

#181

Post by tukantje »

fvdessen wrote: post #145

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

I think his experience in the crypto space is part of the reason why he is against it.

Re: Fintech Engineering Handbook

#182

Post by jvuygbbkuurx »

I wanted to say thanks for this resource.

I'm founding a fintech startup and have been thinking about these things a lot. It is very helpful to have some general validation and guidance to make sure I'm not making huge mistakes.

I really wanted event sourcing, but thought it gets complicated when events have complex validation rules. I ended up with a mix of state and audit logs which works ok for now.

Re: Fintech Engineering Handbook

#183

Post by microgpt »

lxgr wrote: post #104
microgpt wrote: post #95

Earlier quoted context omitted.

idk, why would you store integers as ASCII strings? It's somewhat less efficient.

Because it's much more explicit. Computers are fast, engineering is expensive. You usually never want to optimize prematurely when dealing with monetary amounts.

Even more explicit would be a PNG of the dollar bills. I suggest that.

Re: Fintech Engineering Handbook

#185

Post by microgpt »

SJC_Hacker wrote: post #175
microgpt wrote: post #96

Earlier quoted context omitted.

Charge $0.995 Refund $1.00 Repeat

Charge $0.995 Charge Actual $1.00 Refund $1.000 Alternately Charge $0.995 ERROR CHARGE AMOUNT MUST BE ROUNDED TO NEAREST CENT

In my scenario your payment gateway added a $0.005 fee. You told it $0.99.

Re: Fintech Engineering Handbook

#186

Post by xlii »

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…

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 system. In practice this value is almost never undergoing any operations except for addition and subtraction. Any multiplication/divison etc. is left to specialized systems that return results wrapped in 800 pages of standarization documents, regulations and so on; systems where term "bit flip" is not a joke, but a risk.

As I wrote fintech != fintech, and I know many organizations aren't at that level of scrutiny, but a huge domain of people dealing with others' people money know that charging someone 1 cent too much is a tens of thousands of problems coming their way.

Re: Fintech Engineering Handbook

#187

Post by dxdm »

charlieirish wrote: post #25

Similar style and message to https://shapeofthesystem.com/

Chunks of good advice, tossed and blended into a soup of verbiage generated by a helpful LLM. It sounds smooth and resists being read at the same time. I hope we can get to the point where actually good, helpful prose is generated more often than not.

Re: Fintech Engineering Handbook

#188

Post by fauigerzigerk »

xlii wrote: post #186
oddthink wrote: post #144

Earlier quoted context omitted.

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

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

Re: Fintech Engineering Handbook

#189

Post by trixn »

> 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 bank). Both are a balance sheet extension from a double-entry bookkeeping point of view.

The 4 operations double-entry bookkeeping allows are:

1. balance sheet extension (e.g. making a loan) 2. balance sheet reduction (e.g. loan repayment) 3. asset swap (e.g. a bank buying a government bond with central bank reserves) 4. liability swap (e.g. transferring money from one account to another)

So it may be more accurate to just say that every event that affects the balance sheet must be one of those 4 operations.

Also see "Money creation in the modern economy" - Bank of England Quarterly Bulletin 2014 Q1

Re: Fintech Engineering Handbook

#190

Post by fauigerzigerk »

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…

>"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 doesn't make that statement because arbitrary precision decimals exist. Binary float is not the only and not the most plausible alternative to using integers.

Post reply on HN