Somewhere VERY close to this modeling patterns has always been an interesting use case for us is large-scale visual analysis of crypto investigations, where the ledger gets shown quite similarly. The bit on taxes is funny too, as that's the first thing to get filtered out because it makes the graph messy :) Often, balances aren't initially known, so a post whole-graph-compute step is done to algorithmically enrich nodes after.
You can also do visual tricks here, like collapse 'multiedges' between the same accounts to get a summary of their p2p history. Analytically, this becomes an easy groupby on a ledger dataframe :)
To a lesser extent, we also see fiat $ investigations here too, imagine correspondent banking. I wish more bigco AML forensic accounting did this internally (erp, credit cards, ..), especially as so much is digital now, but we don't see that as much.
An interesting area becomes when you do things like add identity details to the graph, and can then start realizing the "A" and "Alice" and contra XYZ are all the same person. Another, which helps once you have a lot of data, is to start to be able to decloak transaction $1 "food" is a Costco hotdog, or funny buying patterns. Both are where "graph neural networks" come in, which have really advanced over the last few years. We see this kind of things in finance, like risk analysis. We find most folks are at the viz stage vs AI stage, and it's a multi-year relationship to get them from one to another, but a fun one!
---
Edit: Another practical modeling aha here is that a transaction can involve multiple entities. Formally, that is a hyperedge: it's fine for edges to connect more than 2 nodes. (And why languages like datalog are neat here, even if rare.) Visually that's confusing, so a trick is to make the transaction a node and connect it to all the involved accounts. Keeping transactions as event edges between entities can be nicer when zoomed out as fewer nodes, but having the transaction node is nice when zoomed in, and in the limit, there are asymptomatically fewer nodes+edges when doing the transaction node as you replace strongly connected components (quadtratic in edges) with a hub&spoke, which is linear.
Somewhere VERY close to this modeling patterns has always been an interesting use case for us is large-scale visual analysis of crypto investigations, where the ledger gets shown quite similarly. The bit on taxes is funny too, as that's the first thing to get filtered out because it makes the graph messy :) Often, balances aren't initially known, so a post whole-graph-compute step is done to algorithmically enrich nodes after.
You can also do visual tricks here, like collapse 'multiedges' between the same accounts to get a summary of their p2p history. Analytically, this becomes an easy groupby on a ledger dataframe :)
To a lesser extent, we also see fiat $ investigations here too, imagine correspondent banking. I wish more bigco AML forensic accounting did this internally (erp, credit cards, ..), especially as so much is digital now, but we don't see that as much.
An interesting area becomes when you do things like add identity details to the graph, and can then start realizing the "A" and "Alice" and contra XYZ are all the same person. Another, which helps once you have a lot of data, is to start to be able to decloak transaction $1 "food" is a Costco hotdog, or funny buying patterns. Both are where "graph neural networks" come in, which have really advanced over the last few years. We see this kind of things in finance, like risk analysis. We find most folks are at the viz stage vs AI stage, and it's a multi-year relationship to get them from one to another, but a fun one!
---
Edit: Another practical modeling aha here is that a transaction can involve multiple entities. Formally, that is a hyperedge: it's fine for edges to connect more than 2 nodes. (And why languages like datalog are neat here, even if rare.) Visually that's confusing, so a trick is to make the transaction a node and connect it to all the involved accounts. Keeping transactions as event edges between entities can be nicer when zoomed out as fewer nodes, but having the transaction node is nice when zoomed in, and in the limit, there are asymptomatically fewer nodes+edges when doing the transaction node as you replace strongly connected components (quadtratic in edges) with a hub&spoke, which is linear.