Mentioned company founder here, we did not yet! I'm glad to see the ILP project is continuing to progress well though, we should definitely consider it again.
The path finding capability perhaps externalized from ripplenet to W3C ILP being worth it, it's not clear why the market doesn't realize there is such incentive and ILP is not yet widely implemented.
I'm not sure who is the audience of this article. I've worked in fintech and have read several practical guides on ledgers and found them interesting reads. In contrast, this one is laden with overly verbose language whose meaning is unclear, such as
> Transaction-level fund flows give us powerful tools to reason about complex interconnected subcomponents.
This article reads as a fluff piece for investors to me; it's primary purpose seems to be boasting about their own quality while offering only the smallest of breadcrumbs about the underlying system.
I'd be curious if others have a different read, and found this to be more insightful/interesting, and why.
Stripe strongly encourages writing for its own sake. So much so that they run their own press. I suspect the intended audience is whoever is curious for a medium depth primer in what a ledger looks like for a company handling billions of transactions.
As someone in payment tech I found it very interesting.
Hello! I am the author. Thank you for the comment.
While Stripe does love to write, I think our core premise here was that being able to reason mathematically about independent distributed systems was a unique application of a ledger. Likewise, we think the data quality offering is a unique extension since it gives us tools to make improvements to our systems over time.
I appreciate the reply. I think I would have appreciated a more clear description of how you are reasoning mathematically about your distributed systems. Simply claiming that you can and do is fine, but as an engineer I would have loved more practical examples. The only part that I found which touched on this was when you described how to find clearing errors by simply searching for clearing accounts with a non zero balance. Are there other examples of mathematically reasoning that you could share? I don't need/expect a reply here, this question is rhetorical to demonstrate how I think this article could have been stronger for me.
Not the author, but I worked on the Ledger team at Stripe for 5 years.
Clearing is definitely a key part and a large amount of signal can be derived simply through the zero-balance assertion. To give you some more detailed examples of that:
1. System A bookkeeps +$11 and system B bookkeeps -$10 against the same account, where this is representative of A handing off responsibilities to B during some multi-step process and something was off. In practice, this might look like a Charge being handed off from a product team to the team integrating with card networks for submission. There's plenty of reasons this could have gone awry internally from either team like incorrect fee handling, incorrect FX handling, etc.
2. Pipelines reconciling data may bookkeep $11 and -$10 against the same account, where the two events come from different data sources. This could be a difference in Stripe data vs partner reporting or even a difference between two reports from the same partner (e.g. a transaction-level report against a aggregate we've estimated attributions for). Again, there's plenty of reasons this goes wrong like an error on our side, unexpected partner behaviour, actual partner error, or our incorrect interpretation of a complex partner behaviour.
This approach is general in that we don't need to be concerned about what the actual data models or system interactions are to effectively apply monitoring to everything. Another element is to not create a lot of noise on for non-zero balances while they're in an interim state. Some amount of modelling happens to establish an expected time to clear for accounts, and with the right granularity, like "Charges from product teams to integrating teams usually take 10 minutes", "partner report A and B arrive and are processed 1 day apart", or "we receive money from partner A about 2 days after submitting".
In the end, we're trying to boil down every other Stripe system and partner integrations into a Stripe-wide set of discrete states, transitions, and with dollar value they're for. Teams may have their own system diagrams but they'll also have a parallel Ledger event diagram if they handle money which takes consideration to get right (e.g. failure modes, modelling everything well). I suspect that's what the author is getting at with reasoning more mathematically about distributed systems, as we add a twist on a typical system design here.
I don't work at Stripe, but I've talked to a few ledger nerds there.
One thing I'd point out that makes Stripe's ledger different than most others you might have seen or encountered is the granularity of what they consider an account. If you think about a bank ledger, you logically have a single account per customer. Stripe uses multiple accounts for each payment, so processing this number of accounts is a hard scaling problem, especially when most are ephemeral. The saving grace is that this can be done offline and balances can be eventually consistent or materialised on read.
When you have this many accounts, organising them also is a big challenge, since you want to be able to roll them up to something meaningful. Conceptually asset and liability accounts in a ledger represent a financial relationship with an economic actor. If that's the top level account (e.g. how much does bank X owe us right now) you'll want to have a hierarchy of accounts down to each state of each payment. So a lot of effort went into building modelling tools for product teams to design how their financial activity gets represented in the ledger.
Disclaimer: I'm CTO at Fragment (http://fragment.dev) and Stripe led our last round.
To me, this reply is more valuable than the original post simply because it's written without such heavy dependence on jargon. It also does a better job of "showing, not telling" examples of the behavior that need to be handled.
I had to read it a few times too, I'm still not entirely convinced that "being able to reason mathematically about independent distributed systems was a unique application of a ledger" actually parses into anything.
As someone looking to setup $5m/year in a small side business I was frustrated to learn stripe categorically bans what I was planning. I’m on Braintree now and assumed stripe would be better. Now looking for alternatives.
I'm fully aware of how unsatisfying this reply is, but unfortunately I can't seem to find links. It's been a few years since I was deep diving into ledgers and I must have cleared my bookmarks from that time.
> 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?
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.
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.
Interesting ratios between transactions and events: numbers in the article suggest perhaps 50 million transactions a day which correspond to five billion events. So 100 events per transaction on average, which gives some idea of the complexity involved.
