Monthly statements are generated every month and needs to be generated within 10 days of the start of the month.

Timeline

1. On the 1st day of the month, Finance generates a batch of statements for review and checks through them. This list of accounts is posted on #statements-review. This is a private channel. A scheduled job will run and ping #statements-review with a list of accounts that reports-service will generate a statement for. These accounts are top level accounts.
2. If everything is successful, Finance will ping #stmt-service to tell Market Ops to generate monthly statement for all accounts for the month. If it is not successful, Finance team will reach out to engineering to fix the statements. To debug, take a look at (debugging in environments)[./debugging]
3. During the monthly statement generation for all accounts, there may be specific accounts where the statement contains an error. This will NOT be sent to the account holder and the finance team will be notified in #statement-review. Finance will reach out if there is an issue.
4. After the statement is done generating, MarketOps will get the email list from Mandrill and will work with Finance to reconcile any differences.

Engineering involvment

Engineering should only be called in if there is a problem with a statement. For the most part, monthly statements will be between finance and market ops.

Breakdown of Monthly Statement

List of accounts who will receive a statement

The top level account must meet the following criteria:

• Account is not in soft block at the end of the month
• Account is not Deleted
• Account status should be open or suspended The status needs to be effective before midnight New York time of the following month. If an account was opened at 2023-10-31 at 11:59:59 EST, the account will receive a statement for October. Due to the cutoff time being in New York time and postgres database in UTC, when we retrieve the data, the date may say it was opened the following month but is still before the cutoff time.

Receipient Info

The address and email of the receipient is retreieved from AccountProfile message. If address and email does not exist, the statement still gets generated.

Investment Summary

This represents any securities that were bought or sold during the period from HoldingTransaction messages.

Account Balance

This lists all the child accounts with the last 4 of the account number, opening balance, closing balance, and the change in value. The balance information is in the Holding message.

Cash Summary

This table groups HoldingTransaction messages into specific groups and contains a column for the month (this period) and year to date.

• Value of securities sold
• Cost of securities bought
• Trade Fee
• Exercise Cost
• Tax Withholding
• Deposits
• Withdrawals
• Net Seller Proceeds Transferred to Third Party To figure out which section a HoldingTransaction belongs to, we look at the <HoldingTransaction.Type>_<HoldingTransaction.Reason>_<HoldingTransaction.TradeSettlementType> as the key. If there is an error in this table, it is probably due to the key not included in the cash summary.

Cash Activity

This table is a list of all the HoldingTransaction that happened during the month. To get the type of transaction, the table uses the same key as cash summary, <HoldingTransaction.Type>_<HoldingTransaction.Reason>_<HoldingTransaction.TradeSettlementType>. If there is an error in this table, it is probably due to the key not being included in the mapping table. Cash activity and cash summary uses different logic. There are some holding transactions that needs to be split into two rows. Finance will reach out if there are any issues.

Trade Confirm

If there are any auctions that happened and the participant is involved, their trade confirm will be added in their statement. This should match the trade confirm generated at the end of the auction.

Issuer Transaction Summary if the account is an issuer

If there is an auction that happened and the issuer is involved, their issuer transaction summary will be added in the statement. This should match the values that was generated at the end of the auction.

Commands

There are two main command that is created by the Staff Tool:

• GenerateMonthlyStatementsToBeReviewed
• GenerateMonthlyStatementsToAccountHolders

GenerateMonthlyStatementsToBeReviewed

This command is consumed from the orchestrator and added as a job in the redis queue. The generator takes the job and generates a zip file that contains a statement for each unique top level account id. Finance team will download and review the statements. There is no notification sent out for this command if the command was generated via the Staff Tool and was geneated without errors. If it was not, a slack notification will appear in #statements-review. There is no status check on the top level account, but the child accounts needs to be open or suspended, not deleted, and not soft block.

GenerateMonthlyStatementsToAccountHolders

Only users with the monthly statement generation permission can generate this command. This command can be for all account holders or for specific accounts.

For all account holders, the top level account and the child accounts needs to be needs to be open or suspended, not deleted, and not soft block.

For specific accounts, there is no status check on the top level account, but the child accounts needs to be open or suspended, not deleted, and not soft block.

This command is broken down into individual commands, GenerateMonthlyStatementsForIndividualAccount, where each top level account will get their own command and produced onto the queue.

The orchestrator will consume GenerateMonthlyStatementsForIndividualAccount and create a job for the generator. The generator will take the job, get the data, render the pdf, store the document, and produce a SendUserEmail which is consumed by NOTE and StatementGeneratedEvent which is consumed by ACCT.