Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering principles for building financial systems

substack.wasteman.codes

Post reply on HN
Print view View original

71–80 of 112 posts

Re: Engineering principles for building financial systems

#71

Post by jwarden »

amluto wrote: post #25
Terr_ wrote: post #3

> Use consistent rounding methodologies This may also mean promoting them to a named part of the business-domain in code, with their own functions, unit-tests, stuff like "fetch Rounding Strategy Suite by country code", etc. > Use integer representations of time. This one is a little controversial but I stand by it. There are so many libraries in different technologies that parse timestamps into objects, and they all…

> Unix timestamp, or even integer based UTC datetimes work perfectly fine. For serious work, it’s worth noting that leap seconds are not representable in this format. Many financial applications can get away without representing leap seconds, but this is fundamentally a kludge. If you actually need to represent any point in time (according to UTC or any particular timezone), use a representation that actually represe…

There’s a difference between a point in physical time, and a coordinate on a calendar. UTC works great for points in time, both past and future. So UTC is very appropriate for logging, including of financial transactions, where often what matters is the exact point in time something happens and not how that maps to someone’s calendar or the time zone on a server.

But UTC doesn’t work at all for a calendar app, where a calendar entry could for example span a calendar day, in some specific time zone, especially if it is in the future and there is not yet a mapping between that future date and UTC.

Re: Engineering principles for building financial systems

#72

Post by griftrejection »

davidw wrote: post #64
Terr_ wrote: post #11

Earlier quoted context omitted.

> We asked for and got a ruling from the regulators that the time that mattered was the time the API call was processed by the backend I haven't been in that situation, but I imagine I would reach for a "what if it was snail-mail" analogy. "It's dangerous to honor whatever time the bettor wrote by hand, the postmark-time may not be fair if the mailman got delayed because of a half-illegible address or random USPS del…

I wonder if that's the sort of ruling that just got thrown out by the Supreme Court in favor of having courts decide.

[flagged]

Re: Engineering principles for building financial systems

#73

Post by withinboredom »

HWR_14 wrote: post #60
bigiain wrote: post #8

Earlier quoted context omitted.

Also: > Granularity of your financial amounts should ... ... comply with relevant regulations. I worked on a gambling webapp a long time back - we were bound by government regulations on gambling licences to perform all calculations at a precision of one ten thousandth of a cent, and were only permitted to round to cents once at the very end just before displaying a dollar amount to a person. (This suited me down to…

> This suited me down to the ground because I pointed out to everybody that Javascript couldn't be guaranteed to treat numbers and calculations in a way that would keep the regulators auditors happy, Javascript can represent dollar values up to $2.25 billion at a resolution of ten-thousandths of a cent without any loss of precision. I would want all money calculations done by the backend team as a matter of policy. B…

While you are correct that it can _represent_ these numbers with that precision... it cannot operate on them and retain that precision, so DO NOT USE FLOATS TO REPRESENT MONEY. Thank you for your time.

    let a = 35
    let b = -34.99

    console.log(a+b)

    // output: 0.00999999999999801

Re: Engineering principles for building financial systems

#74

Post by withinboredom »

Galanwe wrote: post #4

I wouldn't endorse many of the things stated there. A lot of the points are inaccurate or straight up misleading. > The three main goals of your accounting system are to be (1) Accurate, (2) Auditable and (3) Timely. You forgot "consistent", which is very different from "accurate". Most financial transactions have multiple time dimensions: a trade is requested, booked, filled, matched, reconciliated, paid, settled at…

> No! Delay currency conversion _until conversion occurs_!

Sometimes these are legal requirements one way or the other. In my country, invoices in other currencies are based on the ECB rate of the date of the invoice, no matter what the actual value is when converted.

Re: Engineering principles for building financial systems

#75

Post by erik_seaberg »

DarkContinent wrote: post #53

> Batch is just a special case of streaming No. Designing a system that is always up and running and can process small amounts of data constantly is a completely different problem from designing a system that runs occasionally with a lot of data. For one thing, your output formats are usually different in the latter case (maybe you're creating a PDF for example). Also the high availability requirement just makes thin…

The key is working incrementally, not sitting idle for months and then hammering production as hard as possible trying to get all the deferred work done in exactly one batch.

Re: Engineering principles for building financial systems

#76

Post by erik_seaberg »

willtemperley wrote: post #26

> Use integers to represent financial amounts I followed this mantra when building a trading system. This was the worst engineering decision I ever made - it added complexity and runtime overhead, plus readability was reduced when debugging. If your language has a proper decimal type like BigDecimal in Java or Decimal in Swift, I'd suggest using it. They offer perfect precision for financial applications, are battle…

There's also javax.money.

Re: Engineering principles for building financial systems

#77

Post by darby_nine »

Terr_ wrote: post #3

> Use consistent rounding methodologies This may also mean promoting them to a named part of the business-domain in code, with their own functions, unit-tests, stuff like "fetch Rounding Strategy Suite by country code", etc. > Use integer representations of time. This one is a little controversial but I stand by it. There are so many libraries in different technologies that parse timestamps into objects, and they all…

Honestly we should just abandon all that bullshit and just use TAI for internal representation. Would probably save billions.

Re: Engineering principles for building financial systems

#78

Post by blackhaj7 »

rwieruch wrote: post #13

Related [0], but one week ago I have written about my experiences using TypeScript for an invoicing system, if anyone is interested. It's especially about rounding errors and how to prevent them. Since then we have created hundreds of invoices (and cancellations) and everything worked as expected with minor hiccups in between. [0] https://www.robinwieruch.de/javascript-rounding-errors/

Superb article Robin

Sounds like you really went though a rough time building the invoicing system!

I have read many times about the difficulties of dealing with decimals/rounding but never found an article that nailed the explanation as well as you did

Re: Engineering principles for building financial systems

#79

Post by nyrikki »

ibejoeb wrote: post #29

We're basically talking about bookkeeping systems here, rather than high finance. Use a good relational database. 1. ACID, so you don't have to invent it. 2. Arbitrary precision numeric data types with vetted operations and rounding modes. 3. It does time as well as anyone can 4. Your computations and reporting can be done entirely in SQL. 5. When you get good at SQL or hire someone who is, the reporting is elegant.…

ACID and DTCs will get you in legal trouble with financial systems.

That is part of the reason financial systems backed by SQL are so complicated and fragile while old COBOL code keeps going.

RDBMS tutorials always use ATMs as an example, but you can't 'roll back' with ATMs, you have to use compensating actions.

ACID is useful in many contexts, but actually adds complications to financial transactions.

Think of the ledger as being the source of truth, with the DB as simply a materialized view.

It has applications with edge caching in web apps too. Events as the source of record can help get rid of cache invalidation challenges compared to cache aside or write back.

Two sides errors that don't impact the trial balance is something to search for if you want to know why an ACID DB as the source of truth is problematic in accounting.

Post reply on HN