Show HN: A stateless ISO20022 Financial Compliance API (Bank And Blockchain)(zkorigoapi.com)
zkorigoapi.com
Show HN: A stateless ISO20022 Financial Compliance API (Bank And Blockchain)
https://zkorigoapi.com/
3 comments
former head of eng at a crypto company. I don't have the time to look thru your docs atm but I'd like to.
off the top of my head: stateless is tricky. as I'm sure you know, AML typically includes at least a few rate-based rules. eg: validate that someone isn't evading checks by making several transfers which are all slightly less than the trigger amount. it would be hard to justify paying for a service like this without that kind of capability, depending on the price ofc.
would love to chat more about this though. I'll set a reminder to check the docs later. feel free to send me an email, username at protonmail.
off the top of my head: stateless is tricky. as I'm sure you know, AML typically includes at least a few rate-based rules. eg: validate that someone isn't evading checks by making several transfers which are all slightly less than the trigger amount. it would be hard to justify paying for a service like this without that kind of capability, depending on the price ofc.
would love to chat more about this though. I'll set a reminder to check the docs later. feel free to send me an email, username at protonmail.
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.
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.
I built a stateless blockchain compliance API as a solo developer. Most compliance tooling in the crypto/fintech space is either enterprise-only, closed, expensive, or requires storing user data. I wanted to see how far a fully stateless model can go.
What it does: • AML / sanctions check (advisory only) • ISO20022 XML validation (pacs.008/pain.001) • Cross-border payment rule checks • RWA attestation • Multi-chain wallet validation (BTC, ETH, MATIC, XLM, XRPL, HBAR)
Architecture: • AWS API Gateway + Lambda (Python) • No PII stored • External RPC reads • Single-region deployment • DynamoDB used only for rate limits / usage • No multi-region failover yet
What it does not have: • No SOC2 / ISO27001 • No enterprise SLA • No deterministic RPC fallback yet • Sandbox depends on public RPC stability
Why I’m posting: Looking for technical feedback on: 1. Whether stateless design makes sense for compliance 2. RPC reliability strategies 3. Minimum viable SLA devs expect 4. Anything obviously insecure or naive
Links: Docs: https://zkorigoplus.com/architecture.html Sandbox (no signup): https://zkorigoapi.com
Happy to answer questions.