The staightforward design for a daily snapshot data table would have one record (row) for each day for each account: thus one record of the table might look like (26/3/2008, 0123-456-7, 0, -$8972.15, $10000). This design has a two-part key, namely date*account_number.

A more space-efficient plan is to have the date portion of the key working as a date-valid-from field, such that a new record is only created if the content of any non-date field has changed. For vanilla products like HL or PL, and assuming that the account doesn’t have the DPD counter ticking upwards, this should lead to only a couple of records per month, to capture the monthly instalment movements. For reasons of efficient query logic, an implementation of this design should additionally have a date-valid-to field plus a simple Y/N indicator flag for the “current” (i.e. latest) record for each account.

It is not difficult for programmers to convert between the above two designs on the fly when required by the task at hand.

What advantages might be derived by having daily, rather than monthly, snapshots?

The original post hinted at some, amounting to a better grip on time (and data) granularity at levels below a month. This would be welcomed by modellers, but the cost/benefit would need to be argued. OTOH I think a greater benefit would come in the behavioural information that might be unlocked from analysis of intra-month spending patterns on CCs and transaction accounts. This could have value beyond credit risk, e.g. retention and cross-sell.