Atlas

Each account gets a day-by-day running total, and the whole curve is then shifted so it passes through the balance I know the account started at. Shifting instead of cutting off at that date is what makes late entries safe: a transaction dated before it was already inside the starting balance, so it gets subtracted back out rather than counted twice.

• ·An account with no known starting point is left unshifted, which is just a plain running total.
• ·Quiet days still produce a point, so the chart has no gaps to guess across.
• ·The current balance is worked out a different way from the same rows, and the two have to agree on today.

A transfer is two rows sharing a group id, with the outgoing leg stored as a negative amount. Balance queries can then treat it exactly like income and the negative leg subtracts itself, so there is no special case anywhere. The two legs carry their own amounts rather than mirrored ones, so a wire fee or a conversion still leaves both accounts at their real balance.

• ·Filtering by one account returns one leg, so the list fetches its companion and still shows the transfer as one thing.
• ·Counting transactions collapses the pair, otherwise every transfer would count twice.
• ·Editing one runs as a single database transaction, so a failure can't change half a transfer.

The address is checked after it resolves, not just the hostname, and anything internal — private ranges, loopback, cloud metadata — is refused before the request leaves. Redirects are followed one hop at a time and re-checked each time, since an allowed host can still point somewhere private.

• ·The download is cut off mid-stream at 5 MB rather than fetched and then rejected.
• ·Everything accepted is re-encoded, which also drops whatever metadata the original carried.
• ·If the database row fails to save afterwards, the file is deleted so nothing is left orphaned.