zeekayandHanzo Dev 95aef0c4f6 api: write the transaction to history, so aggregates can see it
History.Append had no caller. The collection existed after the previous commit and
stayed empty, so every window query returned nothing and every aggregate rule
evaluated to false — not to an error. That is the worse failure of the two: a rule
reporting "no velocity" for a window it never read looks exactly like a customer
with no velocity, and nothing anywhere says otherwise.

Measured on nine deposits of 9,400 against a 10,000 limit, before and after.
Before, every one of the nine returned an identical verdict — score 0.075, four
alerts — because the only rules that could fire were per-transaction checks. The
ninth deposit was indistinguishable from the first. After:

  tx 1-2   score 0.525   near-threshold only
  tx 3     score 1.0     structuring-day fires at three
  tx 5-9   score 1.0     structuring-week fires at five, seven alerts

with currency-day at 0.45 on the day's aggregate of 84,600. That is the typology
this product exists to detect, and it was undetectable end to end until now.

The append happens before evaluation, and the order is the point: a transaction
absent from the window it is judged against is judged on a history that stops one
short of it, so the deposit completing a pattern is the one excluded from seeing
it. A write failure refuses the transaction rather than evaluating it against an
incomplete history.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-29 12:06:03 -07:00
S
Description
Real-time AML/CFT transaction monitoring, sanctions screening and case management
2.1 MiB
Languages
Go 88.1%
TypeScript 9.3%
CSS 1.2%
Python 0.7%
JavaScript 0.4%
Other 0.2%