# Finance Rework ###### tags: `design-doc` `gooncode` [ToC] ## Project brief Did you know that almost everything that moves money around digitally has its own bespoke implementation of how that's done? Isn't that... weird as hell? ### Goals - Rework and standardise how digital financial transactions are handled internally. - Implement methods of reviewing financial transaction history. - Introduce interesting methods of committing financial crime. - Allow for greater investigation of suspicious financial activity to counterbalance the massive potential for crime that already exists, and that which would be introduced. ### Non-goals - Change or rebalance aspects of the actual in-game economy itself. ## Structure ### Payment All electronic payments involving bank accounts will be handled by a unified set of procs rather than manually subtracting and adding funds from each account in a manner that's constantly reimplemented. This'll allow for all error handling to be standardised as well. ### Accounts TODO: - Actually remember how bank accounts work. ### Transactions Every digital financial transaction, being those that are conducted with or between bank accounts dealing in digital abstractions of monetary value, could be represented as an abstracted `financial_transaction` datum or similar. This would cover account-to-account transfers, such as when paying for goods and services, or cash withdrawals and deposits. The datum would represent transactions that are complete and authenticated as well as those that have been blocked or failed in some way. Such a datum would include the following information. - The bank accounts involved; `from` and `to`. - In representing cash deposits or withdrawals to or from a bank account, either the `from` or `to` field would be empty or something. - ~~Does this mean that vending machines and merchants would technically have bank accounts? 😬~~ - No, they'd be represented by the station's bank account, or the account of whoever owns it (3 July 2024). - The transaction `type`. - Primarily for denoting and labelling what a transaction is actually doing; whether it's a direct transfer, purchase, or conversion between physical and digital currency. - The `amount` involved. - Represents an integer value. No other denominations of the credit should exist. - Authentication. - The variables that would handle how a transaction would be proven to be coming from a valid merchant. The exact manner in which this will be done will be left as an exercise for the author. Later. - This does not mean that transactions involving illegally acquired funds, goods, or services will be blocked. It's just making sure that the thing moving money between accounts is something that can do that. - `authentication_status`. - Boolean, `TRUE` if this transaction has been verified to come from a legitimate source. - `transaction_status` - Whether or not a transaction has gone through or not. If not, what's stopping it? ### Facilitating transactions TODO: - figure out how that's going to work ## Financial history ## Accessing the financial system