Fintech Engineering Handbook • Hacker News Board

Re: Fintech Engineering Handbook

#71

Post by lxgr » Sat, Jun 27, 2026, 2:43 PM UTC

DetroitThrow wrote: post #45

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.

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.

Re: Fintech Engineering Handbook

#72

Post by lawlorino » Sat, Jun 27, 2026, 2:44 PM UTC

lxgr wrote: post #69

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…

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

Re: Fintech Engineering Handbook

#73

Post by traceroute66 » Sat, Jun 27, 2026, 2:45 PM UTC

> even bad advice

That's putting it politely. Honestly, I think this "handbook" was mostly written by an LLM.

For example, in the immutability section we have this:

   "Separating PII from financial data lets you honor erasure without losing the financial history you’re obliged to keep."

In a financial organisation the two go hand-in-hand for obvious KYC/AML reasons.

Keeping the financial data whilst trashing the customer names, addresses etc. instantly on-demand before the expiry of the relevant time periods is going to leave your entire organisation with a very bad day in the office if a $lawful_body comes knocking for the data to trace a crime.

People going to work in a Fintech should not be relying on a random "Handbook" written by an unknown person in an unknown jurisdiction.

People going to work in a Fintech should only ever work in accordance with their employer's internal handbooks/guidelines/etc which will have been written in conjunction with their firm's lawyers and compliance people to ensure it complies with the laws and reporting requirements in the jurisdiction(s) in which their employer operates.

Re: Fintech Engineering Handbook

#74

Post by f3408fh » Sat, Jun 27, 2026, 2:45 PM UTC

jgalt212 wrote: post #36

> Webhooks are the most common way to receive signals from external systems, but processing them safely is not trivial I see webhooks documented all the time, but I have yet to use them in practice, nor have my customers requested them. Is the above not true, or are they widely used in some sectors and not others?

They are indeed everywhere, but it's possible you don't have a need for them. For example, every time you buy something online using Stripe, the seller receives a webhook indicating that a purchase was completed.

Re: Fintech Engineering Handbook

#75

Post by morpheuskafka » Sat, Jun 27, 2026, 2:47 PM UTC

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.

Re: Fintech Engineering Handbook

#76

Post by morpheuskafka » Sat, Jun 27, 2026, 2:48 PM UTC

lxgr wrote: post #69

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…

> 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'm sure there is something I don't know here, but how is working with integers "brittle"? The only issue I see is rounding down by default, not sure if that is even an issue or not. At any rate, it seems a lot less brittle than floats or bigdecimal style number classes.

Re: Fintech Engineering Handbook

#77

Post by dahart » Sat, Jun 27, 2026, 2:52 PM UTC

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…

What are you referring to with the integers/floats comment? The article says clearly that the rule of thumb is not to use floats and that they’re “almost never” a good idea, that they cause unpredictable precision loss, and recommends integer or BigDecimal types in multiple places. Are you also talking about rationals? So what is the bad advice here, exactly?

For FX, it seems like you’re reinforcing what the handbook says, that there’s no canonical rate. Aside from that, it’s talking about post-resolution records and you’re talking about how to resolve, no? That’s valid nuance of a separate goal, and it’s a fine goal of yours, but doesn’t seem like a demonstration of something missing or wrong.

The article appears to make the very same point about immutability? What are you saying that’s different?

Re: Fintech Engineering Handbook

#78

Post by lxgr » Sat, Jun 27, 2026, 2:53 PM UTC

traceroute66 wrote: post #73

> even bad advice That's putting it politely. Honestly, I think this "handbook" was mostly written by an LLM. For example, in the immutability section we have this: "Separating PII from financial data lets you honor erasure without losing the financial history you’re obliged to keep." In a financial organisation the two go hand-in-hand for obvious KYC/AML reasons. Keeping the financial data whilst trashing the custom…

> Keeping the financial data whilst trashing the customer names, addresses etc. instantly on-demand before the expiry of the relevant time periods [...]

Where does TFA recommend that?

As I see it, it recommends separating PII data you'll eventually have to delete from that you'd probably want to keep forever (including data factoring into your accounting equations/invariants), so that you can delete the former after the relevant recordkeeping periods have elapsed.

> People going to work in a Fintech should not be relying on a "Handbook" written by an unknown person in an unknown jurisdiction.

Sure, but they should also not blindly ignore any ideas and practices presented, or avoid looking beyond their own organization. Ideally, they'll then try to reconcile what they saw with their own knowledge and local regulations etc.

> People going to work in a Fintech should only ever work in accordance with their employer's internal handbooks/guidelines/etc which will have been written in conjunction with their firm's lawyers and compliance people to ensure it complies with the laws and reporting requirements in the jurisdiction(s) in which their employer operates.

Sure, in a world in with only perfect and error-free organizations, that seems like a reasonable approach. But how does one get there without having a conversation such as this one?

Re: Fintech Engineering Handbook

#79

Post by lxgr » Sat, Jun 27, 2026, 2:56 PM UTC

morpheuskafka wrote: post #76

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'm sure there is something I don't know here, but how is working with integers "brittle"? The only issue I see is rounding down by default, not sure if that is even an issue or not. At any rate, it seems a lot less brittle than floats or bigdecimal style number classes.

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.

Re: Fintech Engineering Handbook

#80

Post by traceroute66 » Sat, Jun 27, 2026, 2:56 PM UTC

lxgr wrote: post #78

traceroute66 wrote: post #73

> even bad advice That's putting it politely. Honestly, I think this "handbook" was mostly written by an LLM. For example, in the immutability section we have this: "Separating PII from financial data lets you honor erasure without losing the financial history you’re obliged to keep." In a financial organisation the two go hand-in-hand for obvious KYC/AML reasons. Keeping the financial data whilst trashing the custom…

> Keeping the financial data whilst trashing the customer names, addresses etc. instantly on-demand before the expiry of the relevant time periods [...] Where does TFA recommend that? As I see it, it recommends separating PII data you'll eventually have to delete from that you'd probably want to keep forever (including data factoring into your accounting equations/invariants), so that you can delete the former after…

> 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 new ideas/practices in a regulated firm will involve lawyers and the compliance department.

More than likely that "conversation" will be above most people's pay grade. So you're better off just not wasting your time and adhering to your employer's existing practices.

And for everyone else, its an expensive and high-friction conversation to have if you want to change existing practices.