Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fintech engineering mistakes (2022)

startupwin.kelsus.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Fintech engineering mistakes (2022)

#101

Post by hakfoo »

Brystephor wrote: post #56
JackFr wrote: post #45

Earlier quoted context omitted.

I have worked at banks and fintechs for the past 30 years and honestly have never used anything but a doubles for money with no issues (and a simpler code base.) I understand the sentiment and the potential issues, but it's really kind of domain dependent.

Is storing $1.05 really that much simpler than storing something as 105? Use a long to store money, pretty easy.

If you store things in a hypothetical subsidiary unit, you end up with plenty of corner cases.

1. You might need a different number of "implied decimals". Two decimals is enough for many currencies, but some are three, quite a few are zero, and a few are a janky 1-decimal model. And that doesn't even go near, say, pre-1971 GBP structures.

You'll have to put scaling logic on every interface with the outside world.

2. Even if you do it perfectly, it's going to change. For example, the subsidiary unit on the Icelandic Krona is being removed in a lot of financial APIs right now. You can either change your records, or change your scaling logic, but you've now got an inflection point where you can't reason about the behaviour before the changeover from the current code.

What you need is a decimal type, where you can have 6.33 dollars, 2.167 dinars, or 500 won, and have them all retain fidelity. Sadly, few popular languages provide it.

Re: Fintech engineering mistakes (2022)

#102

Post by Solvency »

submeta wrote: post #58

Have built a fintech startup here in Germany ten years ago. The article mentions lots of important things. Here‘s another one: Time synchronization. It is incredibly important in fintech applications for a number of reasons: 1. *Transaction Ordering:* Financial transactions often need to be processed in the order they were initiated. This is especially crucial in high-frequency trading where trades are often made in…

All of this is exactly why mainframes still exist and still excel at what they do.

Re: Fintech engineering mistakes (2022)

#103

Post by ahtihn »

theptip wrote: post #66

I think this article covers many of the main points, but could be worded/structured better. There are terms of art that more precisely refer to the concepts you need. For “using floating point data types”, it’s even worse; you often need to use strings, for example if you need to store a bank account number “01234567789” will have the leading zero stripped if you use a numeric type. “Updating transactions” would be b…

> if you need to store a bank account number “01234567789” will have the leading zero stripped if you use a numeric type.

This goes for any "number" that is actually an identifier. Phone numbers aren't really numbers either for example.

Rule of thumb: if it doesn't make sense to do math with it, it should probably be a numeric type unless there's a very good reason.

Re: Fintech engineering mistakes (2022)

#104

Post by SideburnsOfDoom »

gytisgreitai wrote: post #92
SideburnsOfDoom wrote: post #88

Earlier quoted context omitted.

> Stripe uses integers [1] a) On web api, so this is by definition data interchange, not "in a language". b) with a currency code to cross check it. c) implicitly "in cents" which needs further documentation - does this mean "pence" when the currency is GBP? How does this work for for JPY? BHD? d) cannot represent fractions of a cent or penny. So: this int plus currency code plus docs is OK but not great, a lowest co…

yet with all those a) b) c) d) they still use that. Point is not "I call stripe api". Point is - those companies, that process wast amount of transactions, use integers. Probably for a reason. And its not in cents rather _minor units_ which you as working in fintech should ought to understand the difference

> And its not in cents rather _minor units_ which you as working in fintech should ought to understand the difference

Erm, did you see the quotation marks around "in cents" ? It's a _quote_ from the docs at the link. The link _that you gave_.

The issue is not "do you or I understand the difference", it's "does stripe" and "do stripe users, after reading that?"

It is simplistic, like the int, and is not making the point that this is great.

Re: Fintech engineering mistakes (2022)

#105

Post by neon_electro »

gunshai wrote: post #63
neon_electro wrote: post #41

Earlier quoted context omitted.

In what way do you think it would've made a difference? Asking as someone who's applied to Block/Square/Cash App in the past.

The difference is small, but mostly as probing questions to interviewers. I take the mind the more you can speak the language the more comfortable people become with you. Here's something small but I was doing a SQL interview one involved a a card_tx table with the amounts stored in integers values in cents. I immediately noticed this and chatted with the interviewer about this. My assumptions were wrong, and the flo…

Appreciate your reply!

Re: Fintech engineering mistakes (2022)

#106

Post by mhh__ »

gpderetta wrote: post #97
mhh__ wrote: post #72

Tip: you can express (city) time "zones" in the type system e.g. London time and New York time.

You can, but because the full set if timezones is only known at runtime, it is not terribly useful. You can statically distinguish a canonical static timezone (say UTC) vs a dynamic ine though. Same for currency.

There are only a few useful times in markets e.g. London, new York etc.

If you don't know then there's no point but the idea is to stop you comparing prices from London close to new York and so on

Re: Fintech engineering mistakes (2022)

#107

Post by JackFr »

Brystephor wrote: post #56
JackFr wrote: post #45

Earlier quoted context omitted.

I have worked at banks and fintechs for the past 30 years and honestly have never used anything but a doubles for money with no issues (and a simpler code base.) I understand the sentiment and the potential issues, but it's really kind of domain dependent.

Is storing $1.05 really that much simpler than storing something as 105? Use a long to store money, pretty easy.

Bond prices are quoted in 32nds (or 256ths) of a dollar. How am I storing that?

Re: Fintech engineering mistakes (2022)

#108

Post by gunshai »

neon_electro wrote: post #105
gunshai wrote: post #63

Earlier quoted context omitted.

The difference is small, but mostly as probing questions to interviewers. I take the mind the more you can speak the language the more comfortable people become with you. Here's something small but I was doing a SQL interview one involved a a card_tx table with the amounts stored in integers values in cents. I immediately noticed this and chatted with the interviewer about this. My assumptions were wrong, and the flo…

Appreciate your reply!

You're welcome, next time I'll try not to have a stroke at the end of my comment. hah. For some reason I can't edit it. shrug

Re: Fintech engineering mistakes (2022)

#109

Post by gpderetta »

mhh__ wrote: post #106
gpderetta wrote: post #97

Earlier quoted context omitted.

You can, but because the full set if timezones is only known at runtime, it is not terribly useful. You can statically distinguish a canonical static timezone (say UTC) vs a dynamic ine though. Same for currency.

There are only a few useful times in markets e.g. London, new York etc. If you don't know then there's no point but the idea is to stop you comparing prices from London close to new York and so on

I've gone as far as encoding bid and ask prices with different types, but tz really has never occurred to me. Closing times are also exchange/contract specific, not just location.

Re: Fintech engineering mistakes (2022)

#110

Post by mikmoila »

jorangreef wrote: post #69
say_it_as_it_is wrote: post #12

Why should anyone have a look at TigerBeetle, a bleeding edge accounting system built with a language no one understands? Since no one understands Zig, no one will be able to maintain TigerBeetle. The company is exposing itself to a great deal of risk with this decision. Adopting TigerBeetle is a colossal business mistake, not an engineering mistake.

Hey, Joran from TigerBeetle here! You raise a fair question. Coincidentally, one of the reasons we picked Zig was for how readable it was, and strikingly so, even for high level programmers who might not understand systems programming or C. Because Zig reads like TypeScript, and we were working in payment switches where the majority of programmers could read that. This particular switch, in fact, had this same busine…

Fascinating info, thanks for sharing this with all the details! Didn't watch your youtube video but do you use any formal systems like TLA+ internally for validating your designs?
Post reply on HN