Auto-payments

Sometimes there is a need for standing orders to be set up, for example as a membership fee, or a need to divert a fraction of a transaction or a period's trading to another account, for example tithing. There are various different mechanisms which need to be implemented independently.

A range of mechanisms is suggested below, each might be suitable for its own module. There are two basic types of auto-payment mechanisms, those which work periodically (the cron-mechanisms), and those which apply to individual transactions at the time. A hybrid is also possible, where the deductions are made periodically, from the total trading volume, say.

Every autopayment mechanism would have the following properties. A name, an indication of value, a target account, a scope of people of transactions it applies to (this could be based on a filter), maximum / minimum quantities to divert. These objects would spawn instances. For example there could be a 5% per transaction payment to the community account for all transactions in currency1, and from the same mechanism but a different instance, I could tithe 10% per transaction to my great-aunt. Thus

1. The system administrator / accountant can set up regular payments applying to groups of people or transactions within the system
2. Individual accounts can set up regular payments from them selves.
3. Every transaction, at its inception calculates the regular payments incurred and shows them in detail on the 'are you sure' page
4. The dependent transactions go into a pending state, until they are confirmed by the second party
5. On confirmation by the second party, the main transaction and its dependents all become marked as complete.

examples of cron mechanisms.

• The simplest method is a monthly fee, which deducts from each applicable account a fixed amount every month.
• a more complex method is demurrage, which would tax periodicially in inverse proportion to the amount of trading. This should stimulate trading!
• a simple variation on demurrage is to penalise every month or week in which no trades occurred.

examples of transaction based mechanisms

• Taxes can be applied according to group-membership, currency, or per-member basis. Later on it may be possible to apply the autopayments to certain job categories also. Perhaps each payment mechanism shouldhave a list of exempt accounts also.
• Another simple method is to deduct a proportion of each applicable transaction, or a fixed quantity, at transaction time. This would involve an additional section to the transaction confirm page, showing how much was being diverted, which mechanism was causing it, and to which account it was going. This tax can be applied to a payment or to a receipt.

John W says I believe these examples are all useful to help in defining the LoCuS specifications. However, I believe we should allow for more flexibility - specifiable at a lower level - to cover not only these examples but also interest charges (which underpins credit unions - and I would like to see the software eventually become sufficiently configurable and secure for such applications) and complex "leakage functions" (with delays).