3 ms·

> Even when we have billions of transactions, a single missing, late, or incorrect transaction immediately creates a detectable accuracy issue with a simple que

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

ilganeli 3y ago
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.
- dwightboyyy 3y ago
  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 https://www.bcb.gov.br/en/financialstability/pix_en
  - lmz 3y ago
    Well at least some people there should be familiar with it - https://docs.stripe.com/payments/pix https://docs.stripe.com/payments/pix
milesskorpen 3y ago
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.
- lijok 3y ago
  Second. That's exactly how we handle all money flow state transitions in our ledgers.
SmellTheGlove 3y ago
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.
lapusta 3y ago
Many systems have concepts of booking date & value date https://support.mambu.com/docs/booking-date-vs-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-account/ https://gocardless.com/en-us/guides/posts/what-is-a-suspense...
kfrzcode 3y ago
Using Hedera hashgraph would be interesting

ilganeli 3y ago

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.

dwightboyyy 3y ago
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 https://www.bcb.gov.br/en/financialstability/pix_en
- lmz 3y ago
  Well at least some people there should be familiar with it - https://docs.stripe.com/payments/pix https://docs.stripe.com/payments/pix

milesskorpen 3y ago

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.

lijok 3y ago
Second. That's exactly how we handle all money flow state transitions in our ledgers.

SmellTheGlove 3y ago

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.

lapusta 3y ago

Many systems have concepts of booking date & value date https://support.mambu.com/docs/booking-date-vs-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-account/ https://gocardless.com/en-us/guides/posts/what-is-a-suspense...

kfrzcode 3y ago

Using Hedera hashgraph would be interesting