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

91–100 of 112 posts

Re: Fintech engineering mistakes (2022)

#91

Post by prottog »

Terr_ wrote: post #59
fatnoah wrote: post #51

Earlier quoted context omitted.

> Use ISO8601 date and time with offset info, always. I think that's just sufficient for all use cases everywhere. I've been a software engineer for almost 25 years and, of all the universal truths I've encountered, implicit and unintended changes to datetime offset are the ones I've seen at every single job.

> I think [ISO8601 date and time with offset info is] sufficient for all use cases everywhere. TLDR: Also, which timezone is used (not quite the same as offset) really does matter--UTC is great but you can't use it everywhere. ________ One of my favorite simple examples of this "here be dragons" for the new developer: Any system that schedules a future calendar-event. Such events are typically pegged, implicitly if n…

> Elbonian Xtremesunshine Time

Ha, good one! One can only hope the Elbonian Parliament will have the sense to abolish this stupid Xtremesunshine time and observe one time zone year-round.

Re: Fintech engineering mistakes (2022)

#92

Post by gytisgreitai »

SideburnsOfDoom wrote: post #88
gytisgreitai wrote: post #86

Earlier quoted context omitted.

Stripe uses integers [1] Adyen uses integers [2] Square uses integers [3] So not sure that the industry would agree with you [1] https://stripe.com/docs/api/prices/create#create_price-unit_... [2] https://docs.adyen.com/api-explorer/Checkout/70/post/payment... [3] https://developer.squareup.com/reference/square/objects/Mone...

> 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

Re: Fintech engineering mistakes (2022)

#93

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

> Point is - those companies, that process vast amount of transactions, use integers.

Point missed, they use that format _on their client apis_, which tells you nothing about what they do in the code that handles it. Now it could be the same internally, in which case the reason is "there's crap code everywhere"

Re: Fintech engineering mistakes (2022)

#94

Post by potamic »

#2 and #3 are pretty solid advice. But the rest of them are nothing specific to fintech. I will also offer a few additional points.

1. Never record an amount without its currency.

2. Reconcile all your data all the time. Never let any data go unaccounted for.

3. Maker-checker is a powerful concept. Embrace it to the fullest across your system.

4. You will be dealing with all sorts of non-standardized financial integrations. A lot. Think adapter pattern as early as possible.

5. You will be answering to multiple regulatory agencies. Create boundaries between them within your system and reduce the surface of compliance as much as possible.

Re: Fintech engineering mistakes (2022)

#95

Post by troupo »

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…

> Financial transactions often need to be processed in the order they were initiated.

And then the banks send you info in batches and out of order :) This happened to us more than once. So the team responsible wouldn't settle/cancel a payment for X even if bank said so. They would read a few other sync batches yo make sure that nothing else changed for X.

Because "Financial transactions need to be processed in the order they were initiated" is a must :)

Re: Fintech engineering mistakes (2022)

#96

Post by Terr_ »

prottog wrote: post #91
Terr_ wrote: post #59

Earlier quoted context omitted.

> I think [ISO8601 date and time with offset info is] sufficient for all use cases everywhere. TLDR: Also, which timezone is used (not quite the same as offset) really does matter--UTC is great but you can't use it everywhere. ________ One of my favorite simple examples of this "here be dragons" for the new developer: Any system that schedules a future calendar-event. Such events are typically pegged, implicitly if n…

> Elbonian Xtremesunshine Time Ha, good one! One can only hope the Elbonian Parliament will have the sense to abolish this stupid Xtremesunshine time and observe one time zone year-round.

I took an embarrassing number of minutes trying to pick a plausible /E.T/ code not already in use elsewhere, then gave up.

Re: Fintech engineering mistakes (2022)

#97

Post by gpderetta »

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.

Re: Fintech engineering mistakes (2022)

#98

Post by boblob-law »

phoehne wrote: post #20

RDMS databases are not a weak point. A bad model of your transaction is a weak point. Depending on the application, and not all applications require this, you may need a consistent read state for the data. Eventually consistent is like saying periodically wrong. Let's say a trader enters a trade for that exceeds there allowed VAR, because they looked at their screen thought they had more dry powder. (Cocaine jokes as…

The bank cannot charge for this unless you as the customer have opted in. See authorized positive settle negative. US based banks.

Re: Fintech engineering mistakes (2022)

#99

Post by juancn »

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…

Also, sometimes currencies require timestamps.

You don't represent money as (, ), you may want to store it as (, , ) to be able to apply the correct exchange rate post-facto, and not have to deduce from the transaction history.

It also helps with cross-checks/consistency verification.

Also, preserve the original timezone in the timestamp. It can save many headaches down the road.

Re: Fintech engineering mistakes (2022)

#100

Post by Brystephor »

indymike wrote: post #74
Brystephor wrote: post #56

Earlier quoted context omitted.

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

Storing is one thing, computation is another :-)

Is computing with doubles faster than with longs or something?
Post reply on HN