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

131–140 of 234 posts

Re: Fintech Engineering Handbook

#131

Post by amluto »

antonymoose wrote: post #121
amluto wrote: post #110

Earlier quoted context omitted.

If someone sells you 12345.55 EUR vs USD at a rate of 1.12345, how many EUR do you think you end up with? Do you think all market participants even agree? What if the rate is 1.123456? For added fun, you can introduce division. Some systems will allow you to sell 12345.55 USD to buy EUR at a rate of 1.12345. The article’s “no lost data” tenet is not really viable when this sort of division is involved. Are you going…

You store the sums on either end, the currencies, the exchange rate and the final sum? No one has .0000145 cents in their account. Rounding occurs in the real world.

> You store the sums on either end, the currencies, the exchange rate and the final sum?

There is a remarkable amount of disagreement as to whether one should do one’s back office work based on the price or based on the quantity of the counter currency.

> No one has .0000145 cents in their account. Rounding occurs in the real world.

Indeed. But you either need to convince all parties to agree to round the same way or you need to accept small errors

Re: Fintech Engineering Handbook

#132

Post by Maxatar »

lxgr wrote: post #71
DetroitThrow wrote: post #45

Earlier quoted context omitted.

Agree with this, working from HFT to payments to account management in the past. You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.

Big decimals are widely available and don’t require any expertise but avoid many of the footguns of implied decimal integers.

Imagine advising someone who explicitly said they work in HFT to use big decimals.

Re: Fintech Engineering Handbook

#133

Post by m00x »

lxgr wrote: post #71
DetroitThrow wrote: post #45

Earlier quoted context omitted.

Agree with this, working from HFT to payments to account management in the past. You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.

Big decimals are widely available and don’t require any expertise but avoid many of the footguns of implied decimal integers.

BigDecimal should be used by almost everyone except for HFT since they're really slow.

Re: Fintech Engineering Handbook

#134

Post by m00x »

morpheuskafka wrote: post #75

A Plaid balance check is NOT a guarantee that the ACH debit you're about to submit will go through. I don't care if the balance is one million, before that ACH can process, every single dollar can be (a) wired out, (b) cleared out by yesterday's ACHs (bills, autopay, whatever) and checks, or (c) spent at debit/ATM. I probably shouldn't tell you why I know that some fintechs don't address this.

It's a good indicator but absolutely no guarantee. I've had to tell project managers this because they didn't understand this concept.

Re: Fintech Engineering Handbook

#135

Post by dumah »

amluto wrote: post #110
antonymoose wrote: post #33

Earlier quoted context omitted.

Having done HFT / low-latency in C++ with a browser based (read: JavaScript) management front-end: Go ahead and use integer cents everyone. It’s practically an industry standard and it works just fine. Anything else is a worse compromise.

If someone sells you 12345.55 EUR vs USD at a rate of 1.12345, how many EUR do you think you end up with? Do you think all market participants even agree? What if the rate is 1.123456? For added fun, you can introduce division. Some systems will allow you to sell 12345.55 USD to buy EUR at a rate of 1.12345. The article’s “no lost data” tenet is not really viable when this sort of division is involved. Are you going…

Of course market participants agree?

Exchanges have calculation rules for every type of mark and payment and will always specify rounding.

Re: Fintech Engineering Handbook

#136

Post by m00x »

gib444 wrote: post #108
krever wrote: post #24

Earlier quoted context omitted.

Hey, author here :) Its at least 80% organic artisanal writing and maybe 20% AI when I needed help with grammar, completeness, broader perspective and everything around.

Native English speaker. I scanned it and IMO there's a slight overuse/misuse of hyphens. Maybe the AI tool could be asked to identify and correct? (The hyphens might be triggering people to think it's AI, too). They mostly need replacing with a full stop or a colon. E.g. "In practice this means storing the amount as an integer in its smallest unit - €12.34 becomes 1234" -> "In practice, this means storing the amount…

Hyphens here are meant to be formatting. You would be correct if this was a literary piece, but handbooks and sheets don't need to use these rules.

Re: Fintech Engineering Handbook

#137

Post by dotancohen »

zdragnar wrote: post #102
lxgr wrote: post #69

Earlier quoted context omitted.

> thank you Rust decimals represented as JSON floats What do you mean? JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec. > If I ever see a monetary value stored in something else than integers I'm going to run away screaming That’s good, then we’ll likely not be working on the same system :) I consider running from “amounts as integer” systems these days (but u…

> JSON doesn’t have floats, it has numbers, and how they’re used after being parsed is not part of the spec. I think that's the problem they were trying to describe. Without a formal spec, systems won't agree on how to handle floats. JS engines treat numbers as 53 bit signed floats, so passing a well defined decimal there through JSON means losing precision at the edges. Money stored in integers gets around the issue…

With I need to represent monetary amounts through JSON, I encode it as a base 10 string and wrap it in quotes so that the JavaScript engines treat it as a string. Conversion back to int happens after the string has been parsed and validated.

I do this with HTTP GET and POST form requests as well. In HTTP, everything is a string (even if that string is JSON).

Re: Fintech Engineering Handbook

#138

Post by gmm1990 »

lxgr wrote: post #88
gmm1990 wrote: post #86

Earlier quoted context omitted.

That’s quite a bit slower to process. At least if you’re converting to integers to do the calculations and the calculations would be quite a bit slower if you kept the big decimal type

True, but this is usually your least concern when you're dealing with monetary amounts/math.

I guess I’m coming at it from an optimizing market data provider perspective once you preallocate memory the next thing to optimize is the string decimal conversion if the feed isnt binary encoded

Re: Fintech Engineering Handbook

#139

Post by [deleted] »

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…

[deleted]

Re: Fintech Engineering Handbook

#140

Post by jyounker »

lxgr wrote: post #94
foresterre wrote: post #89

Earlier quoted context omitted.

As a general rule, you always include the currency code (EUR, SEK, USD etc.) and if possible also the amount of decimals, when using minor units. Currency codes can be found in ISO 4217.

Yes, definitely always include the number of digits, but at your system boundary you still have to pray that whoever you're working with isn't silently dropping that number and re-deriving it from their own, almost-4217-compliant currency database. Redundancy can be great, but it's not a panacea, since it's not guaranteed to be used in an optimal way.

How you expose you present your data to third parties is not how you represent it internally.
Post reply on HN