ACH debit hold-schedule conformance auditPayments & Transfers

Task prompt

Ops thinks some inbound ACH pulls are freeing up funds to members earlier than our hold rules allow. The hold policy is written up in the Bank KB Confluence page 'ACH Debit (Pull) Processing & Hold Schedule' — read that first. It tells you when the hold clock starts, how long the hold is meant to run, and what our own data does and does not record about it. Then get me a conformance read out of the warehouse — our banking data is the zeta3 catalog, rds schema, and every SQL call has to pass catalog 'zeta3' or the warehouse rejects it. The population is inbound ACH debit pulls — money we pull in from an external counterparty into a member account — that reached sent status. Two scoping details to get right, because each one moves the count: count only pulls landing in the member's account itself, not ones landing in goals, reserves or other sub-accounts; and window on when each pull was initiated, not when it was processed or settled, taking the 90 days ending at the most recently initiated such pull in the data. For that population I need three numbers: how many pulls it contains, how many of those pulls had their hold released before the funds-availability date we'd recorded against the pull itself, and the total dollars those early pulls moved. One thing to be precise about: for the release, use the hold-release event we actually record rather than a proxy for it. When you've got it: open a Slack channel called "ach-hold-schedule-conformance-audit", post a summary with the 90-day population and early-release gap and pin it; file a ticket in Jira's Bank Operations project (key BO) titled "ACH debit hold schedule conformance audit"; and reply with ach_pull_sent_90d_count, early_hold_release_count, and early_hold_release_usd.