You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Might be interesting to take a list of transactions and create another list of regular transactions.
Transactions with the same organisation.
Transactions for the same amount.
Transactions that repeat on a specific day every month.
Transactions that repeat on a specific day and month every year.
There has to be some kind of threshold that is passed before considering a transaction common or even regular to stop things like coffee transactions being seen as regular, etc.
In general I expect 1 but not 3 or 4 would mean you were actively re-engaging a service, while 1+3 or 1+4 would mean you were passive and they were re-engaging with you due to a contract stipulating a level of service.
2 is only interesting because it helps us calculate past burn rates and estimate future burn rates. Also the absence of a stable 2 creates variability and risk.
Knowing this would help us:
Reduce burn rates.
Recommend replacements to transactions (bundling or other similar services.)
Get some understanding of the trade-offs between spending £400 on a pair of gucci loafers once, and spending an extra £100 a month at Waitrose.
Further thoughts:
Given a list of transactions from a normalised Counterparty group them by behaviour and tag each group with regular-amount, variable-amount, sporadic-interval, regular-interval. These are patterns. Sum each pattern. Remove transaction groups that are below thresholds of utility. (Although the data would be fascinating, it is probably not worth doing until we have an interesting pictorial/textual representation that will give instant usability.)
Open question about which is more appropriate for a group key at a given point and what do we have access to: Counterparty vs normalised Counterparty vs service/product/utility vs category of service/product/utility
Survival spend
Later on we could create some kind of basic survival spend command that would let you know the amount of money that must always be present in your account for basic living - a total, and a list of transactions that represent the average minimum viable monthly basket. Eventually allowing us to automate current account topups towards this number.
Perhaps there could also be some kind of show transaction next --type=regular command that could tell you the next regular transaction that should be coming out.
The text was updated successfully, but these errors were encountered:
Detect common transactions
Might be interesting to take a list of transactions and create another list of regular transactions.
There has to be some kind of threshold that is passed before considering a transaction common or even regular to stop things like coffee transactions being seen as regular, etc.
In general I expect 1 but not 3 or 4 would mean you were actively re-engaging a service, while 1+3 or 1+4 would mean you were passive and they were re-engaging with you due to a contract stipulating a level of service.
2 is only interesting because it helps us calculate past burn rates and estimate future burn rates. Also the absence of a stable 2 creates variability and risk.
Knowing this would help us:
Further thoughts:
Survival spend
Later on we could create some kind of basic
survival spend
command that would let you know the amount of money that must always be present in your account for basic living - a total, and a list of transactions that represent the average minimum viable monthly basket. Eventually allowing us to automate current account topups towards this number.Perhaps there could also be some kind of
show transaction next --type=regular
command that could tell you the next regular transaction that should be coming out.The text was updated successfully, but these errors were encountered: