account service statement requirements

What are the requirements for bank statements? More generally, for any financial statements by some kind of account provider. This could be a bank, broker, exchange, payment processor, credit card operator, etc.

Take a bank account with monthly statements. You want it to show the start date, start balance, transactions with descriptions and amounts, the end date, and the end balance. You want the start balance plus the changes to equal exactly the end balance.

Zooming out, you want this statement to follow on exactly from the previous statement, and to follow on exactly to the next statement. You do not want any transactions to be able to fall in between the statements, or to be duplicated on both statements. The closing balance of the previous statement must equal the opening balance of this statement, and not by coincidence, but because the end of the previous statement, and the start of this statement, represent exactly the same point in the same transaction log.

Taken together, the statements should form a continuous series, which can be appended together to get a complete transaction log. Statements may be numbered within this series. In any case, attributes required for checking continuation (start and end dates and balances) must be present.

The service provider should issue statements according to a fixed schedule (eg monthly, quarterly or yearly). If they defer issuance of a statement because of account quiescence, this should be clear in the service documentation and on the next statement.

The service provider must deliver the statements to the customer. This may be on paper in the post. It may be via their own online service, for example in a “messages” or “statements” area on the service web site. Or it may be via standard messaging, such as encrypted email. The delivery mechanism must be consistent with the basic inbox metaphor. Items do not disappear from an inbox. Therefore, the service provider must not remove unaccessed statements. For example, a policy that statements are available online whether or not the customer accesses them, but are then removed, breaks the inbox metaphor. If the customer gets behind on saving-off their statements, items start disappearing from their inbox.

If the customer has multiple accounts with the service provider, each account should be reported on in its own statement series.

Where multiple units (currencies, securities, commodities, etc) are handled, these may be treated each as their own account, or in a multi-unit account. In any case, the units of each quantity must be clear. The basic adding-up constraint must apply in each and every unit. If equivalent value in a unit of account is also shown, it must be clear that this is an equivalent value. The basic adding-up constraint applies to the unit(s) in which the account(s) are denominated.

If a log consists of a large number of small transactions, and these can be meaningfully aggregated, they should be aggregated to a granularity of around a day. For example, an order at an exchange may be filled by hundreds of small partial order matches within one day. These can be aggregated to show the totals for those units for that day. To simplify unit identification (for cost basis accounting), units-in for a day should be listed before units-out for that day. Aggregation should only be performed in this way if generally compatible with tax-reporting rules in the customer jurisdiction. The full trade log in such cases is likely still available, but as a distinct item from the account statement.

The statements may be available in csv (convenient for processing) and pdf (accepted evidence format by banks, courts, etc) formats, and any other suitable formats. Statements should show customer name and address on each statement (?).

If provided online, any proposed filename at download time should be sensible (iso8601 date, simple service name, no weird punctuation, perhaps total is in filename, etc).

---

Much of this, especially towards the start, should be obvious. Some of it may be so obvious, that it appears bizarre to even state it.

In the real world, even the most basic of these requirements are not met.

Bitcoin (and generally crypto-commodity) exchanges are bad at this. They tend to give users a big complicated “activity” form, out of which the user can perhaps cajole a suitable statement series.

I also found Paypal statements, for what is a multi-currency account, completely unreconcilable. This was 8 years ago, so perhaps something has changed.

A friend reported that his online shop’s payments via HSBC’s payment processor didn’t contain the basic information required.

Credit Suisse (I think) delete online statements after 12 months. So when I went to catch up on them recently, most of them had disappeared.

Interactive Brokers provide rather complicated reports, and it’s not clear how to get the simplest possible one that still meets these requirements. How to get statements where the basic adding-up constraint applies to every unit, which may include many different types of security? And it is up to the customer to generate their own continuous series over time.