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

81–90 of 112 posts

Re: Fintech engineering mistakes (2022)

#81

Post by lightbendover »

fvdessen wrote: post #14
indymike wrote: post #9

Earlier quoted context omitted.

> There are pros and cons but as long as you do rounding and comparisons correctly it works perfectly fine. This is exactly the issue with using floats where an arbitrary precision decimal with proper rounding is really needed. Easily solved with a good library and if your languages supports it, type, but it's really easy for a dev in a hurry to not use the library and roll some a=b+b*c_rate code that forces some typ…

you can also easily hurry up subtly wrong money math with ints. (overflows, wrong rounding method, etc). So you should not in any case use the default math operators

At least with ints you can capture those issues with intent and handle them properly (as the better libraries that handle money tend to do).

Re: Fintech engineering mistakes (2022)

#83

Post by hannofcart »

scrollaway wrote: post #57
pg_1234 wrote: post #55

Earlier quoted context omitted.

"— If you’re using JSON to pass around monetary quantities (eg. from the frontend to the backend), put them in strings as opposed to the native number type. You never know what the serializers and deserializers across languages will do to your numbers (round them, truncate them etc.)." I'd go a step further and prefix the strings with an ISO currency code ... to stop someone from just feeding it into their languages…

Ergh, I get what you're trying to prevent, but this actively breaks those custom safe parsers we build, and now you have to do some additional active parsing. Please don't do this, just set contractual expectations in your API.

Politely, I think this comment may be incorrect advice.

I think correctness and precision requirements of financial transactions outweighs any devex concerns. Lots of banking and trading APIs do exactly this: pass your currency fields as strings.

Re: Fintech engineering mistakes (2022)

#84

Post by SideburnsOfDoom »

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…

Absolutely, e.. an offset of +2:00 in e.g. 2023‐06‐28T18:00+02:00 could mean Berlin in the summer (Central European Summer Time, clocks will change) or in Johannesburg (South African Standard Time, not summer and clocks don't change). Same offset, different time zone, different clock change rules.

As you note, for some uses this _does_ make a difference and tracking which one you have can in these cases be important.

Re: Fintech engineering mistakes (2022)

#85

Post by hannofcart »

All good points..

One more from me:

- Payment/order processing systems typically involve complex logic.

- One of the best ways we managed to keep complexity in check was to model these as state machines (with the state itself being persisted to DB)

Re: Fintech engineering mistakes (2022)

#86

Post by gytisgreitai »

SideburnsOfDoom wrote: post #35

The recommendation that "developers should use integers to represent money" (with an implicit 2 decimal places, that will work for many but not all currencies) is not a great one. If your language has a dedicated type for monetary amounts, use that. (1) If it does not, but you can make a value object to represent, e.g. amount and currency code, then do that. If however, your language does not have a dedicated type fo…

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

Re: Fintech engineering mistakes (2022)

#87

Post by sokoloff »

tiedieconderoga wrote: post #31
phoehne wrote: post #13

Earlier quoted context omitted.

For example 16.10 is not exactly 16.10 in IEEE floating point. When you do enough operations, and depending on the order of operations, you can wind up several cents off. That sounds small, but can be enough to give your auditors heart-burn. COBOL does BCD arithmetic, (not really but at least conceptually), and it's penny accurate to 31 digits (as per the standard - implementations may have greater accuracy). Frankly…

It would be neat to have a fundamental "money" primitive alongside int, float, string, etc. It might not be simple to implement, though. Off the top of my head, * Can you confidently say that $100>¥10 in an offline environment? * You'd need to support different bases for splitting units to deal with eldritch values such as farthings. * Where is the line drawn? Is a Bitcoin a valid currency? A gold Krugerrand? A bundl…

> Can you confidently say that $100>¥10 in an offline environment?

It’s not even clear what the second currency is. US$100 is over 14000JP¥ or 725CN¥.

If you’re offering me to wager whether $100 is more than ¥10, I’ll take the wager that it is.

Re: Fintech engineering mistakes (2022)

#88

Post by SideburnsOfDoom »

gytisgreitai wrote: post #86
SideburnsOfDoom wrote: post #35

The recommendation that "developers should use integers to represent money" (with an implicit 2 decimal places, that will work for many but not all currencies) is not a great one. If your language has a dedicated type for monetary amounts, use that. (1) If it does not, but you can make a value object to represent, e.g. amount and currency code, then do that. If however, your language does not have a dedicated type fo…

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 common denominator format for interchange, requires further documentation and cross-checking as "100 USD" does not mean 100 bucks and the conversion is currency-specific, and cannot represent all values.

I wouldn't refuse to convert _to and from_ this format at the edges of my application, for data interchange, but the conversion to something clearer and richer IMHO should remain there.

Payment APIs are far from the only use case in fintech, for interest calculations you do have to care about fractions of a cent or penny.

In fact, if your case is "I call the stripe api" ... are you sure you're a fintech and not an online store? Get back to me when you have to interop with FiServ, MasterCard or SAP.

Re: Fintech engineering mistakes (2022)

#89

Post by adenhoed »

SideburnsOfDoom wrote: post #35

The recommendation that "developers should use integers to represent money" (with an implicit 2 decimal places, that will work for many but not all currencies) is not a great one. If your language has a dedicated type for monetary amounts, use that. (1) If it does not, but you can make a value object to represent, e.g. amount and currency code, then do that. If however, your language does not have a dedicated type fo…

It's nice if your language has support for monetary amounts, but usually you end up using multiple languages that interact with the same database model, and you still end up using a built in numeric datatype in your RDBMS of choice.

Three additional 'mistakes' to prevent when dealing with money representations:

1. The definition of a currency might change. For example, some years ago Iceland decided to change the exponent of ISK from 2 to 0. Currencies have different versions.

2. As a FinTech you probably have integrations with many third parties, they don't change their exponents for a currency at the same time. Keep track of what third parties think the correct exponent is at any point in time, and convert between your representation and their representation. Otherwise, you'll have interesting incidents (e.g. transferring 100x the intended amount of ISK).

3. At first you think that counting minor units as an integer is enough, and then you need to start accounting for fractions of cents because sales people sold something for a fee of $0.0042 per transaction. If your code rounds all these fees to $0.00 you don't make any money.

Re: Fintech engineering mistakes (2022)

#90

Post by SideburnsOfDoom »

adenhoed wrote: post #89
SideburnsOfDoom wrote: post #35

The recommendation that "developers should use integers to represent money" (with an implicit 2 decimal places, that will work for many but not all currencies) is not a great one. If your language has a dedicated type for monetary amounts, use that. (1) If it does not, but you can make a value object to represent, e.g. amount and currency code, then do that. If however, your language does not have a dedicated type fo…

It's nice if your language has support for monetary amounts, but usually you end up using multiple languages that interact with the same database model, and you still end up using a built in numeric datatype in your RDBMS of choice. Three additional 'mistakes' to prevent when dealing with money representations: 1. The definition of a currency might change. For example, some years ago Iceland decided to change the exp…

1, 2 - Yeah, there's always a sanity checking and conversion layer around the 3rd party. Currencies do indeed sometimes have 2 versions in play there.

3 - Indeed, the currency type that I referenced "is appropriate for financial calculations that require large numbers of significant integral and fractional digits and no round-off errors"

Post reply on HN