Hi HN,

This started as a practical problem.

I kept seeing small businesses try to run WhatsApp campaigns themselves — using tools they didn’t fully understand — and eventually getting their numbers restricted or banned.

So instead of building another automation platform, I built a managed delivery service.

Clients don’t log into dashboards. They don’t configure workflows. They don’t touch APIs.

They just provide: • a consented contact list • the message they want sent

I handle delivery, pacing, and reporting using WhatsApp Business infrastructure, with conservative limits (currently up to ~10k messages/day).

The goal isn’t maximum scale. It’s boring reliability and fewer mistakes.

This is still early, but it’s being used by real local businesses who prefer not to operate tools themselves.

Curious if this model makes sense outside my market, or if I’m underestimating how much people actually want self-service tools.

Project: https://whateazy.com

Happy to answer questions or criticism.

I built a small internal tool to send WhatsApp campaigns using Meta’s official Cloud API.

It’s intentionally manual: no chatbot, no automation, no scheduling.

The goal is to help businesses send compliant WhatsApp campaigns at scale while avoiding account bans and automation risks.

I currently operate campaigns manually for clients, and this dashboard helps me manage templates, media uploads, recipients, and delivery tracking.

Feedback from engineers and founders is welcome.

I built a single engine that performs the checks banks and crypto platforms usually have to do in separate tools — IBAN, SWIFT, OFAC and blockchain address screening. Everything runs stateless, no data stored, and returns one consistent output. Happy to answer technical questions.

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.

The main reason I went stateless for all validators (banking + blockchain) is to avoid storing any financial identifiers, wallet addresses, or transaction metadata. Every request is processed independently, and all outputs can be reproduced later by re-running the same input through the rule engine.

This reduces: • data retention risk, • breach impact, • compliance obligations (since nothing is persisted), • and audit friction (deterministic logic instead of ML scoring).

The hard parts I’m still working on: • maintaining deterministic outputs across multiple chains with different RPC behaviours • handling ISO20022 structuring without keeping session state • managing rate limits and abuse control without storing user data • making multi-cloud (AWS + Azure) work while remaining fully stateless in both environments

If anyone here has experience building stateless financial or compliance pipelines at scale, I’d appreciate technical critiques — especially around reproducibility, rate limiting design, or RPC reliability patterns.

Thanks for checking this out — happy to answer any questions.

This dashboard is built to be fully stateless and deterministic for banking + blockchain validation. AI hints are optional and non-blocking.

If anyone here works with IBAN/SWIFT data, OFAC rules, AML pipelines, or on-chain analytics, I’d really appreciate feedback on what matters most in real workflows.

Hi HN,

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.

A technical paper examining how traditional banking systems can be connected to blockchain infrastructure in a compliant, auditable, and ISO-aligned manner. The paper outlines integration challenges, settlement constraints, and practical architecture patterns relevant to financial institutions exploring blockchain adoption.