Hacker News new | ask | show | jobs
by reese_john 857 days ago
> Even when we have billions of transactions, a single missing, late, or incorrect transaction immediately creates a detectable accuracy issue with a simple query—for example, “Find the clearing Accounts with nonzero balance.”

How do you deal with float, transactions where the first leg happens in T+0 but settlement is done in T+N ? Do the clearing accounts have a flag/mark allowing for a nonzero balance?

5 comments

We model a timestamp which functionally is "when does this activity go on the books"? We compute clearing both based on this "effective_at" and a "system time" (there are some business functions with known periodicity and it makes for a useful debugging tool).

Long-clearing activity makes for some interesting business cases and long-standing float obviously can lead to some detection noise. For example, Brazil has uniquely long settlement times.

I work with payments in a bank in Brazil and as I was reading the question I thought "interesting question, here we have a great 'delay' in clearances and very old and very complex government-embedded systems to deal with it, funny to see that you know about it too.

btw, are you familiar with Pix? https://www.bcb.gov.br/en/financialstability/pix_en

Well at least some people there should be familiar with it - https://docs.stripe.com/payments/pix
Many systems have concepts of booking date & value date https://support.mambu.com/docs/booking-date-vs-value-date

You may also have suspense accounts for certain types of use cases: https://gocardless.com/en-us/guides/posts/what-is-a-suspense...

Not the author, but know a little bit about this. You’re describing a payable or receivable, depending on the direction of the funds flow you’re thinking about. You’d have an account for the payable/receivable that should clear. If it doesn’t do that by the expected settlement date, someone or something needs to go look and find out why. The settlement date itself should be predictable based on properties of the submitted transaction and the network/scheme reporting.
The general way you'd handle this is with undeposited or in-transit ledgers. Funds would go Account A > Undeposited Account B > Deposited Account B, where they're typically in Undeposited Account B for N days. All ledgers would balance.
Second. That's exactly how we handle all money flow state transitions in our ledgers.
Using Hedera hashgraph would be interesting