Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks, this is exactly the kind of feedback I was hoping for.

You’re right — the moment AML requires behavioural or temporal patterns (e.g., multi-transfer structuring just below a threshold), true statelessness becomes a limitation. My approach so far has been: 1. Keep the core engine strictly deterministic and stateless — single-event checks only (sanctions, IBAN/SWIFT, address heuristics, ISO reconstruction, corridor rules, schema validation). 2. Defer pattern-based AML to external systems that already maintain historical context. The API exposes hooks for institutions to call those systems before/after my validator. 3. Avoid storing any identifiers on my side to completely remove PII liability — it keeps the surface area small but intentionally excludes behavioural AML.

So the design goal wasn’t to replace full AML stacks, but to provide a stateless compliance primitive that can sit at the edge without holding risk data.

If you have thoughts on minimal context retention that doesn’t compromise statelessness (e.g., cryptographic summaries, ephemeral windows, or client-side state patterns), I’d be interested to explore those ideas.

Happy to follow up whenever you get a chance to look at the docs.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: