Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas around common transactions #17

Open
sebinsua opened this issue Dec 23, 2015 · 0 comments
Open

Ideas around common transactions #17

sebinsua opened this issue Dec 23, 2015 · 0 comments

Comments

@sebinsua
Copy link
Owner

Detect common transactions

Might be interesting to take a list of transactions and create another list of regular transactions.

  1. Transactions with the same organisation.
  2. Transactions for the same amount.
  3. Transactions that repeat on a specific day every month.
  4. 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:

  1. 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.)
  2. 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.

@sebinsua sebinsua changed the title Detect common outgoing or incoming transactions Detect common/regular outgoing or incoming transactions Dec 23, 2015
@sebinsua sebinsua changed the title Detect common/regular outgoing or incoming transactions Ideas around common transactions Dec 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant