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

191–200 of 234 posts

Re: Fintech Engineering Handbook

#191

Post by red_trumpet »

trixn wrote: post #189

> Money can’t be created out of nowhere Well, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize a loan as an asset purchase as well, the bank buys a promise to pay from the borrower which is recorded as an asset of the…

> Well, in case of a bank it can. And it happens on a daily basis.

You mean it happens when a bank borrows money from a central bank, right?

Not every balance sheet expansion constitutes the creation of money, e.g. when you put money on your bank account, the bank's balance sheet grows, but the money is not newly created.

Re: Fintech Engineering Handbook

#192

Post by kingleopold »

trixn wrote: post #189

> Money can’t be created out of nowhere Well, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize a loan as an asset purchase as well, the bank buys a promise to pay from the borrower which is recorded as an asset of the…

some engineers and average person sees the entire fiat money as something that needs to be "earn" or get returns from investments only. they dont see how it's literally created as free and out of nothing.

Re: Fintech Engineering Handbook

#193

Post by trixn »

red_trumpet wrote: post #191
trixn wrote: post #189

> Money can’t be created out of nowhere Well, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize a loan as an asset purchase as well, the bank buys a promise to pay from the borrower which is recorded as an asset of the…

> Well, in case of a bank it can. And it happens on a daily basis. You mean it happens when a bank borrows money from a central bank, right? Not every balance sheet expansion constitutes the creation of money, e.g. when you put money on your bank account, the bank's balance sheet grows, but the money is not newly created.

> You mean it happens when a bank borrows money from a central bank, right?

No I mean in the moment the bank grants a loan. The money the borrower receives is new money, its not taken from anywhere else. But at the same time the bank records the credit as an asset which makes it a balance sheet extension.

> when you put money on your bank account, the bank's balance sheet grows

That's true, you hand over cash to the bank which becomes its asset and your account balance is marked up for the same amount. Not all money in circulation is accounted on a bank balance sheet, but most of it is bank deposits. cash is an exception, it's public money, not private bank money. When you "put money in a bank account", i.e. you bring cash to the bank you are essentially selling your public government money to the bank and it pays you with its own private bank money (which it "creates" as well).

But this is only a micro-view of a single event. In the aggregate money is created when either the government runs a deficit or when banks make loans and money is destroyed when taxes are paid or loans are repaid.

Re: Fintech Engineering Handbook

#194

Post by [deleted] »

sho wrote: post #180
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…

> It's always integers unless you have a VERY good reason to do otherwise I don't really agree. This seems like one of those outdated "greybeard rules" which people love to cargo cult, but to me it just comes with its own set of trade-offs, like now you have to think about exponents everywhere and getting them wrong comes with orders-of-magnitude consequences. If you have a modern DB and your languages handle its dec…

[deleted]

Re: Fintech Engineering Handbook

#196

Post by advertum »

sho wrote: post #180
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…

> It's always integers unless you have a VERY good reason to do otherwise I don't really agree. This seems like one of those outdated "greybeard rules" which people love to cargo cult, but to me it just comes with its own set of trade-offs, like now you have to think about exponents everywhere and getting them wrong comes with orders-of-magnitude consequences. If you have a modern DB and your languages handle its dec…

[flagged]

Re: Fintech Engineering Handbook

#197

Post by trixn »

kingleopold wrote: post #192
trixn wrote: post #189

> Money can’t be created out of nowhere Well, in case of a bank it can. And it happens on a daily basis. In fact thats how most private bank money enters the system in the first place either when a bank makes a loan or when it buys any other asset like e.g. a corporate bond (you can conceptualize a loan as an asset purchase as well, the bank buys a promise to pay from the borrower which is recorded as an asset of the…

some engineers and average person sees the entire fiat money as something that needs to be "earn" or get returns from investments only. they dont see how it's literally created as free and out of nothing.

Very true but also understandable because that's how most households perceive it from their micro-economic standpoint. But its very deceptive because it suffers from a fallacy of composition. If households want to earn more than they spend (i.e. save), some other entity must spend more than they earn. This can be somebody taking a mortgage or the government running a deficit. Debt and savings are mirror images of the same thing, two sides of the same coin and we use double-entry book keeping to track them.

It is very insightful to view money as a creature of accounting for debtor-creditor relations rather than thinking of it as some kind of commodity.

Re: Fintech Engineering Handbook

#198

Post by nvlled »

ricardobayes wrote: post #17

Does anyone have more learning resources in this field? Any model implementations, pet projects, anything to get going?

Huh, that's strange, where did all comments to this post go? I remember seeing three, then a few more the day after. Were they bots? They seemed legit recommendations, like the Pricing Money book.

Re: Fintech Engineering Handbook

#199

Post by xlii »

fauigerzigerk wrote: post #188
xlii wrote: post #186

Earlier quoted context omitted.

Quick browse over Stripe API (i.e. not a simplistic payment provider) will show exactly otherwise. Metrics/durations/convexity/vega aren't monetary value, these are calculation values and I'm fine with them being whatever. If you're calculating averages to make decisions based on this I don't care if you're counting dolars or tomatoes. Monetary value is $4.50 and it's representation of actual money passed through sys…

What's your preferred solution to dealing with FX conversions? My issue with using integers everywhere is that FX conversions (or other rates) always come into play, and at that point I'm forced to use something else anyway (e.g. arbitrary precision decimals).

I never had to deal with that. At one place it was so complicated that specialized system took reconciliation over (it got baggage full of context data including exchange agreement details, with boundaries and time-regions plan).

In not-a-fintech we just went with doubles and rounded up (worst case - we get a cent more of a customer).

Though if I had to design today for that, I'd look for non-string serializable decimal, so not "10.123 == (10, 123)" but more like (10123, 3) and serialize in JSON as a value and precision separately.

Yet that's only cause I saw Decimal(10,123) sent in JSON as "10.123" which JSON reader red as 10.122 float and inserted to "1012" to database.

Re: Fintech Engineering Handbook

#200

Post by IshKebab »

jjmarr wrote: post #106
microgpt wrote: post #51

Earlier quoted context omitted.

If you do that though aren't you just reinventing floating-point?

No, because you're doing decimal floating point, which eliminates the rounding errors of binary floating point.

They're both floating point.

https://en.wikipedia.org/wiki/Decimal128_floating-point_form...

What noitpmeder described is just floating point.

Post reply on HN