Protected ReadonlydbProtected ReadonlysearchProtected ReadonlytimeseriesProtectedbustOptionalisManual?: booleanOptionalmethodData?: Optionalraw?: BankTransactionRawUntouched provider payload captured for audit (see BankTransactionRaw).
OptionalaccountNumber?: stringOptionalamount?: stringOptionalbankIds?: string[]OptionalbankTransactionIds?: string[]OptionalcreatedAt?: DbTimestampCriteriaOptionalid?: string[]Optionalmethods?: ("BOOK_TRANSFER" | "ACH" | "ACH_DEBIT" | "RTP" | "SWIFT" | "FEDWIRE")[]Filter on methodData.method — e.g. only the ACH debit postings.
OptionalorderBy?: DbOrderByCriterion<Optionalpage?: numberDefaults to 1
OptionalpageSize?: numberDefaults to 10
OptionalpostedAt?: DbTimestampCriteriaWhen the BANK posted the transaction — the only one of the three
timestamps that is the bank's fact rather than ours. Correlating an
external record (a wire notification, a statement line) against this
table has to window on it: createdAt is when CFX happened to write the
row, which for a hand-keyed row can be days off the money movement.
Optionalq?: stringFree-text filter: case-insensitive substring match on
bankTransactionId, description, and statementDescription; when it
parses as a positive decimal it also matches the exact amount.
OptionalroutingNumber?: stringOptionalstatus?: "POSTED" | "RECONCILED"Optionaltx?: PgAsyncTransaction<NodePgQueryResultHKT, EmptyRelations>Optionaltypes?: ("CREDIT" | "DEBIT")[]OptionalupdatedAt?: DbTimestampCriteriaThe account's IMPLIED balance (credits − debits over its whole
bank_transaction history) sampled at the CLOSE of every day in the
window — the series behind the balance-over-time chart on the admin
bank-account detail panel.
Correlated on the same key as the bank_account_view balance lateral
(bankAccountBalanceLateralSql), so the last point equals the panel's
"Implied balance" figure exactly. A drift between the two would mislead an
operator reconciling the account, which is why the correlation predicate is
shared verbatim rather than re-derived.
Windows and buckets on posted_at — the bank's fact. created_at is when
CFX happened to write the row, which for a hand-keyed transaction can be
days off the money movement.
items is empty (rather than a flat zero line) when the key has NO matching
transactions at all: § 6 of the bank_account_view design distinguishes
"cannot be measured / nothing observed" from "measured as zero", and the
chart must carry that distinction too.
Optionalmemo?: stringFFC memo of a shared-FBO (deposit-memo) account. Narrows the correlation key to that memo's flow through the shared account.
OptionaltimeZone?: stringIANA timezone (e.g. "America/Chicago"). Aligns day boundaries and
localDate output to this timezone. Defaults to "UTC".
Optionalraw?: BankTransactionRawPatch the raw provider payload (e.g. the Paywhere/Metcap raw backfill).
Overwrites raw when provided; callers that must not clobber an existing
value should only pass it for rows whose raw is currently null.
Optionaltx?: PgAsyncTransaction<NodePgQueryResultHKT, EmptyRelations>
Self-bust the read caches after a write on the writer subclass. Drops the folded-
getentry for this row by exact key (all-mode correct — works in memory mode, where tag invalidation no-ops), then the collection bust for every other cached search (a create/update can reshape any list). The folded-getkey must match whatsearchcomputes forget({ id }): all other filters undefined (dropped byserviceCacheKey),page1,pageSize1.Then the implied-balance timeseries for the row's correlation key. Takes the written ROW rather than its id because the timeseries cache has no per-key handle to drop — its keys carry the window bounds and timezone, which a write path cannot know — so the correlation tag is the only way in, and building it needs the row's routing / account / ffcMemo.
A reconciliation-only update (a
BANK_INTERNAL_TRANSFERstamp) does not move the gross implied balance, so this bust is sometimes redundant. Busting on every write anyway is correct and cheap; discriminating would be a way to be wrong.