Create user accounting system that maintains the state of multiple accounts throughout the simulation

[JamesonWelch]

The user (policyholder) will have multiple accounts that can be debited and credited throughout the simulation. As a user, I will have a wallet that is used to pay premiums, a savings account that can be used to pay claims if there are user defections who refuse their portion of the claim, and a dynamic number of 'month buckets' that premiums are paid into.

Each account will be an integer assigned to a variable. Checksums, validation, deciding whether an account has enough or not - all this is handled by other methods in the future.

All accounts except for the wallet needs to contain one month's premium, no less or no more. The accounting system in a later task will define the process of rectifying any deficits that will occur.

User's Accounts

1. Wallet: Integer: Used to pay premiums and savings account deficits. Think of this as the account that the user's bank is connected to.
   • This account is used to pay the premium to the month_0(m_0) account (see # 3).
   • This account also pays the savings account if the savings account has a deficit (savings account has to always equal one month's premium
2. Savings account: Integer: always equal to one month's premium.
   • When a user defects, they deny their portion of the payment of an approved claim. This creates a deficit in the available funds to pay the claimant because the defectors 'blocked' their funds. To make up for this deficit, the total deficit is divided among the remaining policyholders and that amount is taken from the savings account. This means that the claim can be paid in full and the savings account now has a deficit.
3. Month n accounts: Integer: A configurable number of accounts with a minimum of 2 (m_0, m_1) and default of 4(m_0 - m_3) where each account contains the amount of a policyholders' one month premium. You can visualize these month accounts as buckets that the policyholder's pay into. This is essentially a queuing system for payments.
   • The number of month accounts is set by the bundling parameter. See next section
   • The charter of a group would determine the number of 'month' accounts each of their members have, so this number needs to be dynamic and can be configurable with a default of 4 and a minimum of 2 in the simulation.
   • If there are no claims, m_0's balance would get transferred to the next month account (m_1) allowing m_0 to accept the next premium.
   • If the monthly accounts are full when the next premium is due, refunds are given back to the policyholders if there are no current claims. When this happens, the current month's premium essentially 'pushes' the funds from one month bucket to the next and the last bucket, when full, gets refunded back to the policyholder. Refunds always happen after the premium is paid, then the next month, the refund is sent to the policyholder's wallet to assist in paying that month's premium.

Bundling: integer Default = 3

Bundling defines how many month accounts there are (defined by the charter in real life) and how much a claimant receives. But remember, there always has to be a minimum of 2 'month' accounts.

Number of 'month' accounts

Create the number of month accounts equal to the bundling parameter plus one (inclusive). If bundling = 3, there should be four accounts: m_0, m_1, m_2, m_3.

Claimant payments

• bundling = 0: Claimants only get payment from m_0
• bundling >=1: When bundling is set to 1 or greater, claimant gets all funds from all month accounts**

[joshuad31]

The refunds given back to the policyholders in the event there are no current claims happen if all the month accounts are full when the next premium is due.

rephrase: If the monthly accounts are full when the next premium is due, refunds are given back to policyholders if there are no current claims.

[joshuad31]

@JamesonWelch When bundling is set to 1, 2 or 3 The claimant is given all funds in all staging buckets.