There is a certain list of fees charged by different parts of the bank. Those fees are being charged periodically, or on demand with a specific action. If the customer does not have enough funds for a fee to be charged, then the customer’s account begins to owe such fee. The outstanding fees are then charged with respect to a priority across the different types of fees.

Approach using smart contracts

There are different fees / instalments that the domains wish to incur on the customer’s account. The domains are responsible for:

  • Tracking how much the customer owes on the specific fee, and react by applying appropriate consequences. These should be tracked on individual account addresses, one for each fee type.

  • Sending a command (posting) to charge the fee at a moment and of amount specified by the respective domain. These should be charged against the specific fee address. Such fee should be tracked on internal ledger related to fees owed by customers (unpaid). The customer’s effectively gets into debt after being charged the fee.

Example of such tracked fee addresses:

  • Loans account:

    • Overdue principal & interest

  • Main account:

    • Subscription fee

    • Overdraft overdue fee

    • … any other fees that can be unpaid

The smart contract, in turn, is responsible for:

  • Evening the customer’s debt on fees by transferring funds from account’s DEFAULT address to the specific fee address. As this operation pays off the debted fee, this needs to be reflected on the internal ledgers by transferring the amount from unpaid to paid fees.

The fee charging mechanism has to take the fee priority into account when charging the fee. As the priority of fee charging spans across different domains and accounts, a single smart contract related to a specific account does not have enough visibility to prioritize fees across all the different fee types.

Hence, the supervisor smart contract is introduced as a smart-contract having visibility over all of the customer accounts.

The supervisor smart contract captures the postings before they reach the account SC. This allows the SC to apply specific logic related to fee charging across the customer accounts whenever:

  • a fee to be charged is received - The SC runs “fee payment” procedure after the posting is processed (in post-posting), which attempts to even the debts on fees based on their priority

  • account is credited - The SC runs the same “fee payment” procedure as above

  • account is debited - The SC has the option to decide whether or not the posting should be accepted (based on the outstanding debt on the fee addresses)

Visual representation of transfers on account addresses related to fees

The following diagram has multiple sections. Each of the sections describe actions triggered in different occasions.