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

11–20 of 112 posts

Re: Fintech engineering mistakes (2022)

#11

Post by molsongolden »

One more: Timezones

Various platforms use: UTC, the user’s timezone as set in their dashboard, the user’s detected timezone, the timezone of the server that is generating the reports.

Aggregating or reconciling data from different platforms can be a pain if the timezones aren’t clearly indicated.

I’ve had bank statements that didn’t agree to CSV exports of the same data because the servers generating the two reports were in different timezones.

Re: Fintech engineering mistakes (2022)

#12

Post by say_it_as_it_is »

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.

Re: Fintech engineering mistakes (2022)

#13

Post by phoehne »

fvdessen wrote: post #2

You can absolutely use doubles for money. Excel does it and so do many other financial tools. There are pros and cons but as long as you do rounding and comparisons correctly it works perfectly fine.

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's stupid that 63 years after COBOL we're still treating money and currency as an afterthought in languages that are supposed to be business oriented. Proper currency handling should be part of the language.

Re: Fintech engineering mistakes (2022)

#14

Post by fvdessen »

indymike wrote: post #9
fvdessen wrote: post #2

You can absolutely use doubles for money. Excel does it and so do many other financial tools. There are pros and cons but as long as you do rounding and comparisons correctly it works perfectly fine.

> 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

Re: Fintech engineering mistakes (2022)

#16

Post by phoehne »

indymike wrote: post #9
fvdessen wrote: post #2

You can absolutely use doubles for money. Excel does it and so do many other financial tools. There are pros and cons but as long as you do rounding and comparisons correctly it works perfectly fine.

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

I'm tired of having to drag in another dependency and lose operators if I'm doing money math. I can create an experience in C++ that's almost rational, with operator overloading, but most other languages were designed well after we knew that doubles are not sufficient. And there's more than just arbitrary precision. For example,, some currencies use three decimal or no decimal places. Two just happens to be convenient for the Euro and Dollar. In addition, sometimes you carry prices to 3 or 4 places. But you still want banker's rounding. And I shouldn't be able to add Turkish Lira to US dollars, any more than the language allows adding floats and integers, without conversion. Then there's locale correct display for currencies (e.g. $ vs USD and before or after the money amount).

Re: Fintech engineering mistakes (2022)

#17

Post by nickpeterson »

gymbeaux wrote: post #15

This is a nit but is there a better way to say “RDBMS databases?” It feels like saying “ATM Machine”. Could we just say “relational database” or “state of the art database management system?”

A database that just got developed could be called a TardyBMS…

I’m sorry I’ve drank too much coffee this morning.

Re: Fintech engineering mistakes (2022)

#18

Post by agentultra »

Don't be afraid to use formal methods. Queues, retries, event sourcing, payment state handling -- there are "global" properties we desire from these systems: certain things we want to make sure are always true and others that we want to make sure eventually happen. For the single process case, which nearly every developer thinks about, it can seem like a solved problem but we live in a concurrent world with network failures and vendors with errors in their own systems: it's nearly impossible for you to think really hard in your head and be sure that your queue retry strategy will maintain those properties that are important to your business. It's nearly impossible to do this with lightweight, informal testing strategies employed by busy software teams.

By modelling your systems you will learn what the important failure modes are and you will get better at designing systems that are resilient and efficient.

Card payment systems are fairly unreliable peer-to-peer messaging systems. Be prepared for a lot of complexity. Using an event-sourcing architecture is really useful here for that "auditing" requirement and for debugging transaction state when the network sends you messages in error, out of order, or they forget to retry themselves when they promised to, when merchants send bad data, when POS systems do weird things, etc.

Re: Fintech engineering mistakes (2022)

#19

Post by Mordisquitos »

mrbungie wrote: post #7
karmakurtisaani wrote: post #4

Earlier quoted context omitted.

If Excel uses doubles for money, it should be a warning sign. It uses simple numeric data type (I guess just ints) for freaking dates.. I can trace at least a couple of bugs in my career to just that fact.

Apart from its quirks Excel is fine, if you know its limitations. I think the real warning sign would be an analyst/programmer working with Excel and expecting high precision results.

Everything is fine apart from its quirks, if you know its limitations. The problem is when a tool's quirks and limitations are neither exhaustively documented nor can they be inferred from having reasonable knowledge about the base principles of the tool, but are rather learnt by experience (to be read as "through bad experiences").

Re: Fintech engineering mistakes (2022)

#20

Post by phoehne »

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 aside). That becomes a risk management problem. (Also the risk that traders can just use the 'It said I was below my limit' excuse).

If you want an example where consistency is not important, you might be able to overdraw from your bank with your ATM card. The bank is happy for this to be inconsistent, since they can charge for the overdraft.

Post reply on HN