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

91–100 of 234 posts

Re: Fintech Engineering Handbook

#91

Post by traceroute66 »

lxgr wrote: post #83
traceroute66 wrote: post #80

Earlier quoted context omitted.

> any ideas and practices presented Unless its your job to architect stuff, in a financial firm you don't go looking around for ideas and practices. You comply with your employer's practices end of story. If you like looking up ideas and other people's practices then a heavily regulated environment is probably not the place for you. > how does one get there without having a conversation "having a conversation" about…

"Not thinking, just complying" isn't the panacea for good outcomes you make it out to be. You definitely want to limit the amount of excitement, but I've seen many issues caused by legacy formats and practices as well. > You comply with your employer's practices end of story. What if you're the employer ("first engineer" etc.), and there are no practices yet? Fintech almost by definition sometimes includes doing thin…

> What if you're the employer ("first engineer" etc.), and there are no practices yet?

In that scenario the practices will still come first. You're not going to be doing any coding or systems engineering until you've got compliance signed off. You're going to be spending lots of time with lawyers and compliance people.

> Fintech almost by definition sometimes includes doing things from scratch

Yes, but cut through the noise of the typical Fintech fancy website and app and you're still staring straight down the barrel of spending 80% of your time on regulatory compliance.

Try as you might there are only so many ways you can re-invent the wheel for dealing with hard-facts legislation.

Re: Fintech Engineering Handbook

#94

Post by lxgr »

foresterre wrote: post #89
lxgr wrote: post #79

Earlier quoted context omitted.

The brittleness comes from the fact that the number of implied decimal digits per currency isn't always well-defined across all stakeholders and systems. If you're only working in a single currency, there's usually no issue.

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.

Re: Fintech Engineering Handbook

#95

Post by microgpt »

lxgr wrote: post #67
microgpt wrote: post #59

Earlier quoted context omitted.

Why not store them in unary then?

Unary is exactly as expressive as decimal or binary for integers, but somewhat less efficient, so why would you?

idk, why would you store integers as ASCII strings? It's somewhat less efficient.

Re: Fintech Engineering Handbook

#97

Post by lxgr »

traceroute66 wrote: post #91
lxgr wrote: post #83

Earlier quoted context omitted.

"Not thinking, just complying" isn't the panacea for good outcomes you make it out to be. You definitely want to limit the amount of excitement, but I've seen many issues caused by legacy formats and practices as well. > You comply with your employer's practices end of story. What if you're the employer ("first engineer" etc.), and there are no practices yet? Fintech almost by definition sometimes includes doing thin…

> What if you're the employer ("first engineer" etc.), and there are no practices yet? In that scenario the practices will still come first. You're not going to be doing any coding or systems engineering until you've got compliance signed off. You're going to be spending lots of time with lawyers and compliance people. > Fintech almost by definition sometimes includes doing things from scratch Yes, but cut through th…

Please show me the regulation that tells me whether to use big decimals or integers in my internal monetary amount representation. Regulations usually care about outcomes (sometimes high, sometimes low level); they often don't tell you how to technically achieve them.

And if your lawyers and compliance people are actually telling you that you can absolutely not do any financial processing yourself, that the only possible way to be compliant is to license (unfortunately only available in COBOL) etc., you might not actually be working in a fintech, or at least not in the kind this guide seems to be targeted to.

Frankly, this kind of attitude is exactly why banking and payments is as fossilized as it is in some countries, and why fintech is eating their lunch in many cases. There has to be a balance between trying new things and doing what everybody else is already doing.

Re: Fintech Engineering Handbook

#98

Post by mhh__ »

koliber wrote: post #39

Anyone know of resources like this but for capital markets? Things that would allow engineers new to trading equities, options, FX, bonds, and commodities to learn about different flows, market structure, common architectures, and other things that normally you learn from years of experience.

"Trading and exchanges" is the classic one everyone reads for listed markets, I should add.

Re: Fintech Engineering Handbook

#99

Post by gib444 »

lxgr wrote: post #90
gib444 wrote: post #82

Earlier quoted context omitted.

What is with this Twitter esque style of discussion? Post some vague comment with no real stake in the ground, but just reply to follow ups asking for clarifications about the right way. It's exhausting. Why not put all that effort into the initial comment? Vague-posting seems to becoming more popular

If there were a simple one-size-fits-all solution to these problems, there wouldn't be a need for a handbook, nor for a discussion, would there? I can't design everybody's systems here, but I was hoping that sharing some war stories that have cost me days or weeks of work might sensitize somebody to a few non-obvious footguns.

That strawman is so large it would even scare away a human

Re: Fintech Engineering Handbook

#100

Post by simpsond »

lawlorino wrote: post #72
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…

> I consider running from “amounts as integer” systems these days (but usually unfortunately can’t). In the context of Fintech, how do you otherwise resolve floating point rounding issues if not representing amounts with integers?

An integer for the value (scaled by number of decimals) and an integer value for the number of decimals. Different systems may use different values, even for the same currency or asset.
Post reply on HN