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.
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.