Spent-from-two-places envelope balance conformance auditReconciliation & Settlement

Task prompt

Before we green-light spend-from rules on virtual debit cards, product wants to know whether the envelope behaviour we actually shipped matches what we specified. DES-152 is the spec — start there and read it properly, because it is the whole basis of this audit. It makes three separate promises about what happens when a member tags a transaction to a sub-account, and I want each one checked against what the warehouse really shows rather than taken on trust. First promise — the envelope arithmetic. For every sub-account that is still live, meaning nothing that has been archived, nothing quietly archived behind the scenes, and nothing already completed, rebuild what its envelope balance ought to be from the transactions tagged to it and compare that with the balance we have recorded against the sub-account. Count every transaction that was ever tagged to it: the pending ones as well as the posted ones, and the ones that have since been archived as well as the live ones. Tell me how many live sub-accounts you checked, how many of them disagree at all between the rebuilt figure and the recorded balance, and the size of the gap across the whole population netted out, in the direction of how much more the recorded balances hold than the rebuild accounts for. Then name the worst single offender: the one live sub-account where the recorded balance overstates the rebuild by the most, and by how much. Second promise — the shortfall behaviour. The spec allows a tag to be only part-funded by the sub-account, with the rest coming out of available-to-spend. For this and for the third promise below, count every tagged spend on the book regardless of how the money left the account — the fact that we are asking because of a card decision does not mean you should look only at card spends. Count the tagged spends where that genuinely happened, where the envelope covered some of the spend but not the whole of it, and total up how much money came out of available-to-spend across those — the part of each of those spends that the envelope did not cover. Third promise — the one the spec forbids outright. There is one situation the spec says must never result in a tag, by a person or by a rule. Work out what that situation looks like in the transaction data and count the tagged spends that are sitting in it. And then the part I am most suspicious about. That last promise talks about a rule doing the tagging, so before we widen any of this to virtual cards I want to know whether those rules are firing at all. Some sub-accounts have a spend-from rule standing against them — the instruction that quietly tags matching card spend to a savings goal so the member never has to do it by hand. When you count those instructions, count only the ones aimed at a savings goal and not the separate sort we keep for bill reserves — that is a remark about which instructions to count and nothing else, so do not let it narrow the population you audited above. Instructions that have been deleted plainly do not count either; I mean the ones still in force. Tell me how many of the live sub-accounts have one standing against them, and then, out of those, how many have never once had anything tagged to them at all. A rule that has never fired in its life is the strongest evidence we have that the automatic tagging is quietly broken, and that shortlist is the first thing engineering will ask for. Two cuts of the above that I specifically want called out. Separately from the count of spends in the third promise, tell me how many live sub-accounts are in the state where that has happened on every single tagged spend they have — the envelope has never once contributed a penny to anything spent against them. Those go to the top of the remediation list. And of the rule-backed sub-accounts you counted just now, how many are already showing a balance that disagrees with their own history? That second one is what the card decision actually turns on, so do not let it get lost in the write-up. Two more things before you write it up. First, to put a face on all this: how many of the live sub-accounts are caught by all three problems at once — the balance disagrees, and there is at least one part-funded spend sitting against it, and at least one tag made when the envelope was empty? That is the number that goes in front of the exec review, because those are the members having the worst time of it. Second, the shortfall promise turns up somewhere else entirely and I want it checked there too. We also top these sub-accounts up on a schedule, and when one of those scheduled runs cannot draw the money from wherever it normally would, it is allowed to fall back to available-to-spend — the same behaviour as the second promise, just automated rather than done by hand. Tell me how many scheduled top-up runs have actually fallen back that way across everything we have processed, and how much money they pulled out of available-to-spend in total. Then close it out: open a Slack channel called "spent-from-two-places-audit", post your conformance verdict with the headline numbers in it and pin that message; file the Engineering ticket in project ENG (project key ENG) titled "Spent from two places envelope conformance — DES-152"; and reply to me with active_subaccount_count, non_reconciling_subaccount_count, net_balance_discrepancy_cents, top_offender_id, top_offender_gap_cents, partial_carryover_tx_count, ats_draw_total_cents, zero_envelope_violation_count, rule_backed_subaccount_count, never_fired_rule_count, envelope_never_funded_subaccount_count, rule_backed_nonreconciling_count, all_three_breach_count, ats_fallback_run_count, and ats_fallback_total_cents.